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Preface 

The purpose of this Redpaper is to provide guidance for the preparation of 
business process models, developed with the WebSphere® Business Modeler, 
which will ultimately be monitored by the WebSphere Business Monitor. The 
model preparation, including business measure development, and the 
configuration of monitoring, including dashboard design, is the main focus of this 
paper. There are other resources from IBM® for guidance on general process 
modeling, deployment, and execution. 

By use of examples to illustrate the concepts of continuous improvement 
management, this Redpaper presents the mechanisms for an organization to: 

► Model and simulate a business process. 

► Define business measures. 

► Monitor the application to observe key performance indicators. 

Throughout the paper best practices are highlighted to provide additional 
guidance for using WebSphere Business Monitor and WebSphere Business 
Modeler and for optimizing the value of the developed solutions. This paper will 
evolve and be updated as more best practices are identified. 
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Introduction 


IBM understands that sophisticated enterprises require a comprehensive 
approach to meeting their strategic business requirements. This understanding 
drives our Business Innovation and Optimization approach, which includes 
industry expertise, best practices, and market-leading software — specifically, for 
the context of this paper: WebSphere Business Modeler, WebSphere Integration 
Developer, WebSphere Process Server, and WebSphere Business Monitor. 

Business Innovation and Optimization is based on a continuous performance 
improvement cycle that consists of four core activities: 

► Modeling the business requirements 

► Assembling the appropriate assets 

► Deploying the models with the appropriate instrumentation (and consequently 
running the automated models) 

► Managing the executing systems (Figure 1) 

The managing activity is accomplished through monitoring the events emanating 
from the business operations and supporting IT infrastructure, analyzing the 
events and causality, and initiating the appropriate actions in response to 
circumstances, for example, redeploying resources, altering business rules, or 
revising business processes. 


Assemble 

Assemble existing and new 
assets to execute and manage 
business processes 



Deploy 

Deployment of models, 
policies and assemblies to 
realize business intent 


Model 

Capture, simulate, 
analyze, and optimize 
business models to reduce 
risk and increase flexibility 

Figure 1 Business Innovation and Optimization lifecycle 


Manage 

Real-time visibility and 
analysis of business 
information for timely 
and coordinated action 


The Business Innovation and Optimization model-based approach provides 
several advantages: 

► Alignment across the business, including IT; deep process and operation 
insight for risk management and change. 
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► Informed decision-making and action; processes are integrated end-to-end; 
practical reuse of the business management assets. 

► Flexibility to adapt to dynamic changes and efficiency in capturing business 
intent to ensure solution fidelity (how well the solution implementation reflects 
the requirements of the business). 

► Enablement of service-oriented, end-to-end process management for your 
organization based on a service oriented architecture (SOA). SOA 
component applications enable businesses and organizations to plan, 
develop, implement, and improve their processes. 

The IBM SOA foundation is an integrated, open set of software, best practices, 
and patterns that provides you with what you need to get you started with SOA. 
The SOA foundation provides full support for the SOA lifecycle through an 
integrated set of tools and runtime components that allow you to leverage skills 
and investments across the common runtime, tooling, and management 
infrastructure. 


WebSphere tools and runtime 

This Redpaper provides examples and focuses on the continuous process 
improvement pattern for Business Innovation and Optimization lifecycle 
management, which utilizes: 

► WebSphere Business Modeler — A business process modeling tool that 
enables you to model, design, simulate, analyze, and generate reports for 
your business processes; integrate your new and revised process; and define 
your organizations, resources, and business items. 

► WebSphere Integration Developer — Allows you to build flexible, composite 
applications by wiring service components with minimal skills based on 
service-oriented architecture (SOA). 

► WebSphere Process Server — A business integration server, it is built to 
support solutions created based on service-oriented architecture (SOA). You 
can use it to build advanced business processes and traditional business 
integration such as enterprise application integration. 

► WebSphere Business Monitor — A business activity monitoring environment 
that displays key performance indicators and metrics through dashboards 
and scorecards, which are portal pages (through WebSphere Portal). The 
WebSphere Business Monitor also provides corrective action capabilities. 

Together, these applications enable businesses and other organizations to plan 
and implement a unified business process strategy based on realistic simulations 
and observed data. 
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Figure 2 illustrates how the WebSphere tools are utilized within the Business 
Innovation and Optimization lifecycle. The focus of this Redpaper is on process 
and business measure modeling and how key performance indicators (KPIs) are 
realized on the WebSphere Business Monitor dashboard. 


1. Process modeling: 

Build and refine process model 
Simulate what if conditions 
Select processes for monitoring 


2. Business Measure modeling: 

Define metrics, KPIs, events 
Create metrics for capturing working 
duration and decision paths 



Figure 2 Modeler to Monitor to Modeler 

Note that the common event infrastructure (CEI) allows service components to 
emit events that can be captured by WebSphere Business Monitor for real-time 
monitoring of business processes. 


Organization roles for a Modeler/Monitor solution 

The audience for this paper includes managers responsible for WebSphere 
Business Monitor projects. The feedback provided by real-time business 
measures gives managers better control over their areas of responsibility. With 
measures in place, deviations in performance are detected earlier, enabling 
managers to take the proper action at the right time to minimize costs or make 
the most of opportunities. In addition, business measures provide insights into 
how various operations will be affected by changes in input rates and external 
and internal factors. 
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The following organizational roles may be involved in different aspects of a 

WebSphere Business Monitor implementation: 

► Process analyst — This role creates business process models and performs 
analysis on them. This user would also perform the analysis to determine how 
measures for a particular business process model support the organization’s 
business measure requirements. They also ensure that the information 
required to collect those measures is carried over to the deployment model so 
that the model can be monitored properly. The process analyst also collects 
the feedback from the WebSphere Business Monitor and imports into the 
WebSphere Business Modeler to perform additional analysis. 

► Process measurement analyst — This role is responsible for defining the 
business measure model and all of the key performance indicators (KPIs), 
metrics, and the associated triggers, counters, and timers. 

► Integration specialist — This role has an in-depth understanding of the 
events and event types that are contained within the event catalog of the 
common event infrastructure. They are responsible for generating the DDLs 
and deployment artifacts from the business measure modeler and then 
importing, into WebSphere Integration Developer, the appropriate event 
schemes that are used to associate the correct event for the calculation of 
KPIs and metrics in a given monitoring context. They are also responsible for 
generating the DDLs and deployment BPEL artifacts from the WebSphere 
Integration Developer. 

► Database administrator — This role is responsible for managing and running 
the DDL scripts that define the schema for the WebSphere Business Monitor. 
They also perform any tuning on the various WebSphere Business Monitor 
databases to maximize performance and link any third-party reporting tools to 
the databases to enable additional reporting. 

► IT administrator — The WebSphere Business Monitor administrator is 
responsible for ensuring that the WebSphere Business Monitor and its 
associated prerequisite software have been deployed. They are also 
responsible for deploying the business measure models that are generated 
by the business measure modeler. The WebSphere Business Monitor 
administrator is also the primary user of the WebSphere Business Monitor 
administrative console and is responsible for the WebSphere Business 
Monitor configuration. 

► Dashboard designer/administrator — The dashboard designer is 
responsible for creating meaningful dashboards that use the predefined 
views, as well as custom dashboards or portlets. They are responsible for 
fulfilling the organization’s standards and design principles for configuration of 
the dashboards. This user is also responsible for determining which 
users/groups have access to which dashboards. 
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► Business manager or associate — The business manager or business 
associate roles represent the users that may interact with the dashboards in a 
very frequent manner. They use views that show more real-time information 
in order for them to manage the work they are responsible for. This user takes 
administrative actions and has alerts assigned. This user can access 
information about employees in his organization. This user analyzes historical 
information to determine how much work was processed and the breakdown 
of what work was processed for trending and forecasting. 

► Business executive — The business executive user is primarily interested in 
viewing a high-level set of KPIs and metrics and making decisions as a result. 
They are the primary users of the Scorecard views as well as views that 
provide trends using more of the historical data. This user is less prone to 
take corrective or administrative actions directly, but will likely collaborate with 
business managers responsible for the actions. The executive receives alerts 
that are more high level in nature. 


Examples 

This paper utilizes two examples to illustrate the concepts and actions described 
for using the WebSphere Business Modeler and WebSphere Business Monitor. 
Each section will continue with each example. The two examples are: 

► Verification of an account (from the fictional JK Enterprises) 

► Handling an order (from the fictional ClipsAndTacks, Inc.) 

Verify Account process 

In this example, the fictional JK Enterprises is under increasing pressure to 
reduce costs through simplification, while improving their ability to serve their 
customers. When a customer orders a new product or service, they expect 
immediate notification of the results despite the fact that risk management 
practice dictates often-complex validations of the customers’ viability. Customers 
might submit a request over the Web, and then phone the call center or their 
sales person or account manager to inquire on the status. 

They are receiving 1 0,000 applications for new accounts per year. As hard as the 
coordinators are working, credit checks remain in the in-basket for an average of 
two days. During this time sales people, account managers and call center 
representatives have a very difficult time handling inquiries regarding the status 
of the application. JK Enterprises wishes to improve their ability to process 
requests for new accounts quickly; today they are limited by the number of credit 
checks these teams can handle. 
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They are improving the entire Account Management Services process (Figure 3). 
However, this example focuses on the Verify Account sub-process, which is the 
third step in the overall process, following Account Sales and Account 
Application, and preceding Activate Account. 
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Figure 3 Overview of the Account Management Services process 


A JK Enterprises' high-level business objective is to improve customer 
satisfaction. Specifically, management wants to achieve the following goal: 
Increase customer satisfaction by 15%. 

Since customer satisfaction is difficult to measure, a more direct object was 
defined: Reduce the amount of time to execute the Verify Account process, 
thereby reducing the amount of time that a customer waits to be notified if their 
new account was opened or rejected. 

► To facilitate this objective, the following could be automated: Automate credit 
checks, information gathering, and the setup of approved accounts in 
Customer ODS, A/R, Billing, and General Ledger. 

► Given an improved process, the percentage of new account applications that 
take longer than a day should be less than 14.5%. This leads to a specific 
KPI. 

► Naturally, a related KPI would be the tracking of the average duration for 
processing new account applications. 


Handle Order process 

The Handle Order process example used throughout this Redpaper is the same 
example that is used in the IBM Redbook Business Process Management: 
Modeling through Monitoring Using WebSphere V6 Products, SG24-7148. 

ClipsAndTacks is a fictional, medium-sized office supply company operating in 
eastern Canada and the northeastern United States. The company has grown 
slowly and has achieved a significant customer base through its excellent 
customer service practices and reputation for quality products. Most 


Best Practices for Using WebSphere Business Modeler and Monitor 7 







ClipsAndTacks customers are businesses; ClipsAndTacks does not allow 
accounts for non-business customers. 

ClipsAndTacks has been losing customers to Office Market, its main competitor. 
Office Market is a national office supply chain that provides an online catalogue 
and ordering process for its customers. From Office Market's Web portal, 
customers can view available products and submit an order 24 hours a day, 7 
days a week. 

As a result of the customer surveys, ClipsAndTacks 1 management has decided 
that the Handle Order process has to be updated so that it can fill orders in a 
shorter amount of time. Company management wants to establish an automated 
process that shortens order turnaround time, especially for trusted repeat 
customers. The planned improvements include a new Web-based ordering 
system. 

ClipsAndTacks' high-level business objectives are to attract more customers, 
increase revenue, and reduce costs. Specifically, management wants to achieve 
the following goals: 

► Reduce the average time from when orders are received to the time they are 
shipped to three days. 

Based on this, a KPI was developed to track the average duration for 
processing an order, with a target of less than three days. 

► Achieve an order approval rate of 90% or better. 

Based on this, a KPI was developed to track the percentage of approved 
orders, with a target of 90%. 


Modeling 


Modeling is the first activity of the Business Innovation and Optimization lifecycle, 
and has its own iterative lifecycle, in addition to the iterative feedback from the 
Business Innovation and Optimization Management activity. The modeling 
lifecycle includes the capturing and collaboration on process design, and then 
the simulation and analysis on the models in order to optimize them for reduced 
risk and increased flexibility. 

Business modeling is a key capability that helps capture what matters to 
businesses, such as business processes and policies, key performance 
indicators, business events and situations, and the corresponding response 
actions. 
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The models serve as the basis for monitoring and optimizing business operations 
and the supporting IT infrastructure. The right solution can be identified for a 
business environment by projecting outcomes before implementation. Further, 
processes can be quickly adjusted in the future when business factors change. 

Modeling for a project intended to utilize WebSphere Business Monitor includes 
the following general steps: 

► Developing the core business processes and the business measure model 
with WebSphere Business Modeler. 

► The core business processes are exported as BPEL processes to the 
WebSphere Integration Developer for further modeling to assembly with 
external services, and then deployed to WebSphere Process Server for 
execution. 

► The business measure model is exported from WebSphere Business Modeler 
for WebSphere Business Monitor. 


Preparation 

After processes have been selected for modeling, the next step is to collect the 
information about this process. The preparation for the modeling phase includes 
establishing a modeling methodology. The chosen methodology drives how 
the modeling efforts will progress, the types of information that will be collected, 
and the nature of the iterative modeling cycle. 


Best practice: A team must be assembled that includes a wide variety of 
skills, such as: 

► The ability to facilitate group sessions 

► Managing of potential conflict situations 

► Listening and reflecting back descriptions provided by process experts 

► Envisioning processes from the details available in documents and 
facilitated sessions 

► The ability to use the appropriate modeling tools 

► Business process domain knowledge (expertise) 

► Supporting IT application and infrastructure domain knowledge 
(awareness but not necessarily expertise at this point) 
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Establish a modeling methodology 

There are many modeling methodologies available to guide an organization in 
developing the models required to populate a Business Innovation and 
Optimization lifecycle. The purpose of this section is not to recommend a specific 
methodology. However, any methodology that is chosen should satisfy a few 
requirements to provide models that will enable the Business Innovation and 
Optimization lifecycle to optimize the organization’s ability to perform and adapt 
the models that are developed. An appropriate modeling methodology will 
identify and drive the implementation of changes required to operate an 
enterprise effectively and efficiently. A methodology enables realization of the 
defined strategic capabilities and the fulfillment of the strategic intents. 


Best practice: A modeling methodology separates working projects for each 
phase of development: current state, what if? state, and future state. The final 
version of the current-state project, and then an assessment of the current 
state, is usually the baseline for the what-if project. The what-if project will 
likely utilize benchmarks, future goals, operation requirements, and changes 
in business conditions, and then can be tested through simulation. When the 
what-if project produces the desired results, it serves as the baseline for the 
future-state project. The future-state project will be available for applying the 
feedback from the management of the running of the processes, thereby 
continuing the cycle of Business Innovation and Optimization. 


Listed below are some of the key benefits that a modeling methodology provides: 

► A common communication vehicle for the users, management, consultants, 
and technology implementation teams of the project 

► A confirmation of the business system (process, organization, technology), 
the flow, and the relationships between the processes and activities 

► A basis to harmonize processes across different geographic locations, 
divisions, or subsidiaries and identify the best of breed in execution 

► A basis for identifying problem areas within the existing processes and 
opportunity areas where process redesign, new applications, or enabling 
technologies could improve those processes (as in package selection) 

► Communication to obtain buy-in to the future process design (whether it is 
business processes, IT processes, or management system processes, and 
so forth) 


Best practice: A new WebSphere Business Modeler workspace should be 
created for each engagement, and all processes for the engagements should 
be contained within the one project. 
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Six Sigma 

Considered a best practice by many, the Six Sigma approach is based on the 
statistical analyses of process errors and failures and their causes. The 
WebSphere tools and runtime allow an organization to identify and analyze 
process defects and failures in real time. WebSphere Business Modeler can 
provide the detailed answers to what-if questions that allow process managers to 
choose an optimum solution to a process problem. WebSphere Business Monitor 
can supply real-time and historical process data that show process-performance 
trends and the effects of process changes. 

The Six Sigma process is built on the five DMAIC steps, which are supported by 
the WebSphere Business Modeler and WebSphere Business Monitor, as 
described here: 

1. Define: 

- WebSphere Business Modeler serves as a repository of core and 
supporting processes and components such as sub-processes, activities, 
services, resources, and KPIs. 

- This repository facilitates reuse, consistency and saves time across Six 
Sigma teams. 

- Existing models, data serve as a basis for goal definition. 

2 . Measure: 

- Representative time and cost data may be added to As-Is models. 

- Simulation then allows current performance to be evaluated; probabilities 
and distributions may be added. 

- Exception path modeling allows the impact of defects to be better 
understood. 

3. Analyze: 

- Advanced simulation supports Design of Experiments/What .//'scenario 
testing (results are saved for comparison reporting). 

- A rich set of reports and queries may be customized. Results may be 
exported. 

- Activities may be classified (cause and effect, value add, regulatory, 
others as required) and reported/viewed. 

4. improve: 

- Alternative To-Be processes may be designed, simulated, and evaluated 
using dynamic case and comparative analysis. 

- Results may be exported for additional analysis and graphing. 
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- BPEL and UML export facilitate IT handoff, reducing implementation cycle 
time (improved process). 

5. Control: 

- KPIs are defined in Modeler and used by Monitor. 

- Monitor captures events and data to drive and display real-time KPI 
performance. 

- Notifications (defined in Modeler) alert process owners and manage 
escalation and resolution. 

- Data captured sets up next As-ls improvement cycle. 

Component business modeling 


Best practice: Component business modeling (CBM) is a technique for 
modeling an enterprise as non-overlapping components in order to identify 
opportunities for innovation, improvement, or both. 


A business component is a part of an enterprise that has the potential to operate 
independently, in the extreme case as a separate company, or as part of another 
company. A business component is a logical view of part of an enterprise that 
includes the resources, people, technology, and know-how necessary to deliver 
some value. 

A business component map is a tabular view of the business components in the 
scope of interest. In the CBM view, an enterprise is simply a collection of 
business components that are networked together (Figure 4). 
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Figure 4 An example of a component business map 


Note: As of Q1 , 2006, the Component Business Modeler is only available 
through IBM Consulting Services. It is not directly available to IBM customers. 


The business component view enables a clear focus on the strategic capabilities 
of the business. And, by applying various evaluation criteria to the components 
(for example, cost, revenue, strategic fit) we can develop clear, prioritized 
improvement plans. 

Business Strategy Mode 

Business Strategy Mode (BSM) extends the capabilities of WebSphere Business 
Modeler through an Eclipse plug-in. It is an intermediate step between the 
Component Business Modeler and the WebSphere Business Modeler by 
providing a simpler mode than the present WebSphere Business Modeler Basic 
Mode for collaborative work on high-level business processes with clients 
(Figure 5). 
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Figure 5 An example of the Business Strategy Mode Modeler 


Note: As of Q1 , 2006, the Business Strategy Mode is only available through 
IBM Consulting Services. It is not directly available to IBM customers. 


The process models created with the Business Strategy Mode are simpler in that 
they only contain processes, tasks, connections, artifacts, decisions, 
annotations, roles, and swimlanes. Thus, the Business Strategy Mode is useful 
for creating high-level process maps in teamwork sessions. These processes 
can then be exported to WebSphere Business Modeler for more detailed work. 


Best practice: Business Strategy Mode helps core WebSphere Business 
Modeler users (business analysts and process specialists) communicate with 
the business users (executives, strategy consultants, LOB managers, end 
users) they collaborate with, who otherwise use PowerPoint or Visio. 
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The Business Strategy Mode also contains a KPI catalog capability that provides 
a head start for developing a business measures model within WebSphere 
Business Modeler. KPIs are associated with processes with a model and are 
indicated by a KPI marker in the upper left corner of the process shape 
(Figure 6). 
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Figure 6 A Business Strategy Mode process with a KPI marker 

Defining business goals 

A key aspect of any methodology should be the definition of business goals 
and/or linking the goals to the business processes. The goals, and more specific 
objectives, will lead to an effective measurement system, that is, will drive the 
development of the business measures. 

In fact, it could be said that the entire Business Innovation and Optimization 
lifecycle does not function properly if the business goals do not drive the 
development of the business measures. 


Best practice: The following are recommendations for ways to optimize the 
development of business goals: 

► Establish goals based on the organization’s current performance given 
what information they have. These goals may change when the actual 
performance evaluation, through monitoring and analysis, begins providing 
results. 

► Use simulation results to glean new goals, objectives, and targets. 


Process modeling 

Business processes are a series of related business activities aimed at achieving 
one or more business objectives in a measurable manner. Typical business 
processes include receiving orders, marketing services, selling products, 
delivering services, distributing products, invoicing for services, and accounting 
for money received. They represent how work gets done across internal and 
external organizations by describing how a business harnesses performers 
(people and application systems) and passive resources (knowledge, equipment, 
physical assets, capital) in order to execute the capabilities of these resources, 
realize the strategic capabilities and value propositions, and to create valuable 
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outcomes. Models allow us to isolate, break down, expose, or explore 
components of a business process. 


Best practice: The American Productivity & Quality Centre (APQC) defines a 
process classification framework (PCF) to serve as a high-level, generic 
enterprise model or taxonomy to encourage organizations to see their 
activities from a cross-industry process viewpoint instead of from a narrow 
functional viewpoint. Use the PCF as a guide for scoping process mapping. 
Where possible, the processes should be scoped within the boundaries 
identified in this framework. 

Set up a process catalog within a WebSphere Business Modeler project for an 
every level 1 process within the APQC Process Classification Framework. All 
level 2 and level 3 processes required from the PCF should be established 
within this process catalog. 


Process models are usually successively refined, and the iterative refinement 
uses the same basic constructs at each level. The chosen methodology drives 
the iterative development of the processes. Platform-specific details have to be 
added using tools that target the runtime environment (for example, WebSphere 
Integration Developer). 

WebSphere Business Modeler is used to specify business process models using 
the properties of process activities, their costs, their timings, their data, the 
applications to be used, and work-assignment rules for staff. The WebSphere 
Business Modeler supports cascading detail levels within business 
processes — from high-level summaries to specific tasks, roles, and 
dependencies. The WebSphere Business Modeler also provides analytical tools 
to optimize business process modeling. After processes are captured within the 
WebSphere Business Modeler, you can simulate process performance under 
varying environmental factors, such as time and cost. 

Key process modeling concepts include: 

► A process is chronological. Accurate models must therefore be oriented on a 
time line (in general, from left to right in sequence). 

► Processes begin with triggering events, and work their way through to 
significant business results. 

► All tasks or activities are assigned to roles that are meaningful to people in the 
business. Be sure you have captured all relevant roles, which may sometimes 
be outside of the client’s company. 

► Flow modeling should display how objects or data (or both) are transferred 
and where they are going. The majority of business problems stem from 
interdependent relationships, which are best identified in a flow chart. 
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► A process can be modeled in a hierarchical fashion and can be viewed from 
many levels. That is, processes can contain other processes. 

► The choices made for decisions, which occur within a process, determine 
which of all potential paths will be taken. 


Best practice: Establish organization standards or guidelines for developing 
models and naming model elements. This results in greater understanding of 
the processes throughout the organization even though the models may be 
created by multiple people. Examples of such standards include: 

► Establish naming conventions for each type of modeling object. For 
example, all process names could have the following format: 

verb + (adjective/descriptor) + noun (example: Verify Account) 

Note that the word Process is not in the name of the process. Likewise, the 
words Task or Activity are not used in naming activities. 

- To help with report outputs, names should be 32 characters or less. 

- To help with readability, all words should be capitalized. 

- As-ls processes should be suffixed with Al and To-Be processes with 
TB. 

Note: Some practices use the terms Current and Future instead of 

As- Is and To-Be. 

- If an activity is global and used outside of a single process, it should 
have a prefix to indicate the scope of its use. 

► Establish a set of standard nouns, verbs, and acronyms that are used for 
naming activities. Since many words have similar meanings, setting which 
words should be used and which should not be used will add to the 
consistency across models. For example, use the verb complete rather 
than finish or end. 

► Establish standards for versioning methods associated at the process 
model and artifact level to provide requirement traceability. (Note that the 
use of Rational® Requisite® Pro can assist in fostering this rigor and 
discipline.) 

The use of an annotation object in the upper-left corner of the diagram can be 
used to provide information about the context of the process, its relationship to 
other processes, and the process owner. 


Configuring processes for execution and monitoring 

To prepare the processes for WebSphere Business Monitor, the processes must 
be configured to be exported as BPEL processes. This allows the export of a 
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BPEL process to the WebSphere Integration Developer for assembly, 
deployment, and execution. 


Best practice: For all processes, even those that will be configured for BPEL 
export, create the models in the Basic editing mode. This will speed up the 
initial iterations of the models as they are being developed. 


This type of process modeling is done in the WebSphere Process Server editing 
mode. There are some restrictions of the types of modeling elements that can be 
used in this mode so that the process is compatible with BPEL. For example, the 
following items cannot be added to the process: 

► Business item instance 

► Do-while loop 

► For loop 

► Notification broadcaster 

► Notification receiver 

► Observer 

► Global repository 

► Timer 

In addition to defining the basics of the process for execution, additional 
information pertaining to KPIs that will be tracked by the WebSphere Business 
Monitor must be added to the process (see “Business measure modeling ” on 
page 25). 


Examples 

The two examples, Verify Account (from the fictional JK Enterprises) and Handle 
Order (from the fictional ClipsAndTacks, Inc.), are continued for process 
modeling in the following two sections. 

Verify Account process 

In this process, as shown in Figure 7, the customers’ specific information is 
verified and the Account Coordinator performs an initial application review. If an 
acceptable current credit report is on file, the request is approved and priced. If a 
current credit report is not on file, a new credit report is requested. The credit 
checks result in a low, medium, and high risk rating. Low risks are automatically 
approved and priced. High risk customers are asked to provide additional 
documentation. The account manager, for final determination of the request, 
reviews high risk and medium risk customers. 
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Figure 7 Verify Account process (three parts) 


Best Practices for Using WebSphere Business Modeler and Monitor 19 








In these steps, the account coordinator reviews the customer application and 
researches information about several different systems to determine whether a 
credit report is required. If a credit report is not required the customer application 
bypasses much of the process. If a credit report is required, the account 
coordinator calls or faxes the credit agency to request a credit report. Since we 
call/fax customer service (and require faxed credit reports) the current agency 
does not provide us favorable pricing. Since obtaining multiple credit reports is 
expensive and time consuming, we are not able differentiate between high and 
medium risk customers. This results in a large number of declined requests — far 
above the typical percentage for our industry. 

Note that the evaluation of the credit risk is defined in a business rule that is 
accessed by the Credit Assessment Business Rule task (the last task in the top 
box in Figure 7). This means that the business rule can be modified 
independently of the process. The managers have a Web-based interface to the 
business rule and can modify the rule’s parameters-based real-time conditions, 
as we will see when reviewing the results from the WebSphere Business 
Monitor. 

Finally, the account coordinator generates an approval. The pricing for the 
approval is determined by referencing complicated paper manuals. 

In “Business measure modeling ” on page 25 we describe how the extensions to 
the process are modeled for the KPIs that will be tracked by the WebSphere 
Business Monitor. 

Handle Order process 

At ClipsAndTacks, the Handle Order process was modified to address the new 
business goals. The process involves a customer calling in to place an order 
(Figure 8). 

If the customer has an account, then the order is taken and set for review. If the 
customer is new, then an account must be created before the order can be taken 
and sent on. The creation of a customer account is common to a few 
ClipsAndTacks processes, so this can be handled in a re-usable sub-process 
(Figure 9). 
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Figure 8 Handle Order To-Be process 



Figure 9 Reusable Receive Order To-Be sub-process 


A new feature of the process is that orders are checked with a business rule to 
see if they can be automatically approved. The automated business rule also has 
a higher threshold for manual approval than did the original process. Automatic 
approval is very quick and also reduces the number of orders that are placed in 
the in baskets of order managers. 

Automatically approved orders go through a second check to see if the 
customer’s account is in good standing. This check can also be done without 
human intervention. The orders of customers in good standing are sent directly 
to the warehouse for fulfillment. If the customer’s account is not in good standing 
or the order was not automatically approved, then the order is reviewed by an 
order manager. 

The order manager determines whether the credit risk is acceptable. If not, the 
order is cancelled and a notification is sent to the customer. If the risk is 
acceptable, the order is sent to the warehouse for fulfillment. 

In the next section, we describe how the extensions to the process are modeled 
for the KPIs that will be tracked by the WebSphere Business Monitor. 
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Static analysis 

Static analysis can be used to validate aspects of the model such as the 
following: Are values missing, are values correct, are relationships between 
elements correctly defined (for example, is the correct role assigned to a task), or 
are paths correct (that is, there are no cycles or paths that can not be reached)? 
There are four different kinds of static analysis that can be performed on process 
models: resource analysis, organization analysis, process analysis, and general 
analysis. 

► Resource analysis presents information about the usage and allocation of 
roles and resources to tasks (activities) in the process model. 

► Organization analysis presents information about the association of tasks 
(activities) to organization units and locations. 

► Process analysis provides analysis of paths in the models, such as cycles 
and paths that cannot be followed, and identifies activities by categorizations, 
such as resources, classifiers, or locations. 

► Matrix analysis is the main general analysis to use. It maps the associations 
between two selectable element types in the model, for example, resources 
and activities. 


Simulation 

The simulation feature of WebSphere Business Modeler can be useful for 
helping design and validate a business process prior to creating business 
measures and deploying the processes. These are the steps involved in 
performing a simulation: 

► Validating the model 

► Generating the snapshot 

► Editing the simulation profile and settings 

► Running the simulation 

► Analyzing the results 

When you simulate a process, the tool adds a simulation snapshot as a child 
element of the process in the Project Tree view. A simulation snapshot is a 
record of the complete process model at a moment in time. This record contains 
a copy of all the elements of your project that the process may use, such as 
business items, resources, and global tasks. You may want to create multiple 
simulation snapshots for the same process after making changes to the project 
or to the process itself, so that you can compare the effect of these changes. 
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Best practice: Use the static process cases summary analysis to determine 
the number and probability of the possible cases that exist for the process 
(based on the number and layout of decisions). The larger the number of 
cases, the larger the number of tokens that will be required to perform a 
reasonable simulation. For example, a process with four cases requires only 
20 tokens to be generated, while a process with 100 cases requires 1000 
tokens to be generated. Too few tokens creates unreliable results and too 
many tokens increases the time for simulation and analysis of the results. 


You can use simulations to observe a process in action (Figure 10), to examine 
the statistics that it generates as it runs, and to perform analysis on the 
simulation results. You can make changes to a process or to other model 
elements (such as available resources) and then run a new simulation to do a 
comparative analysis of the before and after simulation results. By doing this, you 
can assess the costs and benefits of making changes to your business 
processes. 



Figure 10 An example of a simulation in action 
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Simulation is a valuable tool for not only performing business process 
re-engineering (that is, To-Be processes). It is also a tool for helping in the 
identification and design of business measures. 


Best practice: Simulation can support business measure development in the 
following ways, as examples: 

► Simulation results can provide guidance for setting targets, margins, and 
limits for KPIs. 

► Comparison results between As-ls and To-Be versions of the process can 
provide guidance for the percentage improvements that are called for by 
business objectives. 


Figure 1 1 shows sample simulation results from the redesigned Verify Account 
process. The results show an average elapsed duration of about 1 hour and 9 
minutes. This is much less than the maximum target of 8 hours. Thus, this gives 
confidence to the managers that the planned KPI targets can be achieved when 
the revised process is assembled and deployed. 


Case Name 

Distribution 

Success Status 1 Average Bapsed Deration 

Average Throughput 

Case 1 

88% 

Succeeded 

58 mrutes 16.09 seconds 

1.029722 work item / hour 

Case 2 

6% 

Succeeded 

2 hours 17 rnnutes 51.333 seconds 

0.435238 work item / hour 

Case 3 

4% 

Succeeded 

3 hours 40 rnnutes 47 seconds 

0.27176 work item / hour 

Case 4 

2% 

Succeeded 

17 mnuUrt 

3.S2&A12 work items i bou ■ 

Weighted Average 

1 hour 8 mrutes 43 117 seconds 

0.873126 work item / hour 


Figure 1 1 Simulation results for the Verify Account process 


Figure 12 shows sample simulation results from the redesigned Handle Order 
process. For this simulation the elapsed duration is longer than the target for the 
planned KPI to measure the process duration. However, the simulation was 
based on a single shipper, which turned out to be the bottleneck that caused the 
longer times. For the actual deployed process, management has decided to use 
two shippers for the process, which should reduce the processing time so that 
the target of three days can be satisfied. 
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Figure 12 Simulation results for the Handle Order process 


Business measure modeling 

Financial measurement systems generally fail to explain performance gaps in 
terms of operational details, timeliness issues, error frequency, and 
accountability. By linking these types of measures to the business process, 
performance gaps can be more accurately explained. 

Companies have to create their own measurement systems to achieve optimum 
performance levels. In general, such systems enable an organization to: 

► Determine where they are by establishing an initial As-ls performance level. 

► Establish goals based on their current performance. 

► Determine the gap between a set of desired goals and current performance 
levels. 

► Track progress in achieving desired performance goals. 

► Compare and benchmark their competitors' performance levels with their 
own. 

► Control performance levels within predetermined boundaries. 

► Identify problem areas and possible problem causes. 

► Develop more robust business plans. 

► Drive desired results at any level: organization-wide, departmental, or at the 
process level. 

► Help decision makers base their decisions on performance-related facts 
rather than solely on opinion and speculation. 

The abilities to measure performance and make the information available to 
decision makers when it is needed are the critical factors in creating and 
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maintaining a high-performance organization. An organization that does not have 
the right information available at the right time cannot accurately assess its 
current condition. The creation of a business measurement system is therefore 
critical to organizational success. 

The long-term benefits of a measurement system for the whole organization lie in 
satisfying its customers, monitoring progress, benchmarking processes and 
activities, and driving change through clear actions, performance plans, and 
strategies. The right business measures help organizations change successfully 
in the right directions with the least cost. Measurement facilitates improvement. It 
is much easier to improve something that is measurable, or quantifiable. Process 
improvement can be done effectively and efficiently when the process is 
measured. 

A business measure model describes how a runtime for business monitoring (a 
monitor) performs these steps. A model is required because different businesses 
define different metrics and key performance indicators, have different event and 
information infrastructures, and have different situations to which they are 
sensitive, and all of these change as the business evolves. A business measure 
model allows customizing a monitoring infrastructure accordingly. 

A business measure model is an extension of a process model within 
WebSphere Business Modeler and provides the ability to define what is going to 
be monitored. The business measure model defines business measures, such as 
key performance indicators (KPIs) and metrics ; their dependencies on inbound 
events or external data sources; conditions warranting business action (business 
situations; and outbound events that notify of these. 

The KPIs and metrics can be defined to be used for monitoring, analysis, and 
situation detection purposes. Upon completion, the schema for the WebSphere 
Business Monitor database as well as the executable code to deploy the 
business measure model to the WebSphere Business Monitor will be generated. 

Key concepts for business measure modeling include: 

► Define key performance indicators and metrics. 

► Identify situation events based on KPIs and metrics. 

► Determine appropriate event types and events associated with calculating 
KPIs and metrics. 


Business Measure Editor 

A process model is extended to include business measures by way of the 
Business Measure Editor within WebSphere Business Modeler. The Business 
Measure Editor provides a separate environment for each process to define 
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business measures and the KPIs that will be tracked with WebSphere Business 
Monitor. 

To get started on the business measures, the predefined business measures 
have to be created and the Business Measure Editor environment enabled. This 
is done by ^ right-clicking the process in the Process Tree and ^ selecting 
Create Business Measures... (Figure 13). 


S kg Account Verification 
B Cq Business items 

(Q Business items 
(j-i Business item instances 
B Processes 

Processes 


Account Verification (To-Be) 


[+! kj) Tasks 
4] Services 
[+1 Q Resources 
Cgj Organizations 
Cl Classifiers 
Events 
E Qg Reports 
[+: C(|'., Queries 
4) Q)-., Predefined resources 
El Cjg) Predefined organizations 
B Cl Predefined classifiers 
E Cfe Predefined business measures event 
m Business groups 
B kg ClipsNTacks 

0l_I 1111 


0 


New ► 

Import 

Export 

Open 

Print... 

Reports... 

Add to Business Group. . . 
Simulate 


Create Business Measures. . . 


Export Diagram... 

Copy 

Delete 

Rename 


Version ► 

Static Analysis ► 

Publish 


Figure 13 Adding business measures to a process 


After the business measures have been created, the business measures for the 
process can be seen in the Project Tree (Figure 14). 
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Figure 14 Business measures within the Project Tree 

You open the Business Measure Editor just like you open a process from the 
Project Tree. You can have both the Business Measure Editor and the original 
process diagram open at the same time. 

If you make any changes to the original process after the business measures 
have been created, you have to synchronize the process with the Business 
Measure Editor. You can do this by -O right-clicking the process in the Process 
Tree and ^ selecting Synchronize. 

The following sections briefly describe where and how business measures are 
added to a process model. 

KPIs and aggregate metrics 

When the Business Measure Editor is first opened (Figure 15), it is open to the 
KPIs and Aggregate Metrics tab. This is where you can add business measures 
that are aggregated across multiple instances of the process by the WebSphere 
Business Monitor. KPIs and aggregate metrics are defined in this tab. Clicking 
any of the KPIs or the KPI folder in the Business Measure Tree (left side of 
Figure 15) displays the view so that you can add KPIs. 
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R Cg] KPIs 

filo Average Order Fulfillment 
Vjlo Percent of Orders Approved 
-Pa Metrics 

rrR Percentage of Orders Shipped 
q Check Order Aggregate Metric 
rrR ship Order Aggregate Metric 


KPIs and Aggregate Metrics Diagram Technical Diagram 


▼ KPIs 

This section provides information about key performance indicators (KPIs) calculated across multiple runs of the process. 



| Add 1 1 Remove | 


Situation events 

Optionally, specify situation events that are sent when the value of the selected business measure changes. 

Event definition | Event attribute | Attribute type [ Attribute calculation 


O Send only once (or, if "On condition" is set, send only when the condition changes from false to true) 
O Send every time (or, if "On condition" is set, send every time the condition is true) 

On Condition 


□m 


E=i Attributes £3 Simulation Control Panel Errors (Filter matched 0 of 345 items) Technical Attributes View 


Figure 15 Business measures view for defining a KPI 


R) Clicking any of the aggregate metrics or the Metrics folder in the Business 
Measure Tree displays the view so that you can add aggregate metrics 
(Figure 16). 


a Os kpis 

|Bo Average Order Fulfillment 
UBo Percent of Orders Approved 
- Cg] Metrics 

rR Percentage of Orders Shipped 
rR Check Order Aggregate Metric 
'rR Ship Order Aggregate Metric 


■ Metrics 

This section provides information about the metrics calculated across multiple runs of the process. 


Name 

I Type 

Aggregation function 

Aggregation source 

Percentage of Orders Shipped 
Check Order Aggregate Metric 
Ship Order Aggregate Metric 

Double 

Integer 

Integer 

User Defined 

Total 

Total 

( ( 'Ship Order Aggregate Metric' / 'Check Order Aggregate Metric' )) x 100.0 
Check Order Counter 
Ship Order Counter 



T Situation events 

Optionally, specify situation events that are sent when the value of the selected business measure changes. 



O Send only once (or, if "On condition" is set, send only when the condition changes from false to true) 
O Send every time (or, if "On condition" is set, send every time the condition is true) 

On Condition 


□tZD U 


KPIs and Aggregate Metrics Diagram Technical Diagram 

la Attributes i-3 Simulation Control Panel Errors (Filter matched 0 of 345 items) Technical Attributes View 


Figure 16 Business measures view for defining an aggregate metric 
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To return to the KPIs and aggregate metrics after working on the Business 
Measure Editor Diagram (described next), ^ select the KPIs and Aggregate 
Metrics tab at the bottom of the view. 

Business Measure Editor Diagram 

By clicking the Diagram tab at the bottom of the view, you can open the 
Business Measure Editor Diagram (Figure 17). This diagram is a reproduction of 
the original process, but the diagram also display icons indicating where 
business measures have been added to the process (see the icons in the upper 
left corner and the icon above the second activity in Figure 17). The business 
measures that are defined for this diagram are not aggregated with the 
WebSphere Business Monitor. That is, they apply only to a specific instance of 
the process. Each individual instance will have its own copies of these business 
measures and maintain their occurrences or calculations separately. The 
aggregate metrics and KPIs (defined above) can combine the individual instance 
values of the business measures defined through the Business Measure Editor 
Diagram. 


£ *Order Handling ( 1 st T o-Be) T 


<£§ Account Verification (To-Be) Account Verification (To-Be) Business measures 


st To-Be Order Handling Process 


I , New Web order form, implemented 
as Web application/JSPs. (No 
business mearsures/monitoring 
takes place on this global process. 





iS^i Order Handing Po 




Default: Orders a 

e reviewed by Order Manager 



then the order c; 

an order is less than $750, 
be automatically approved without review. 

<1 

KPIs 

and Aggregate Metrics Diagram Te 

chnical Diagram 



Figure 1 7 Business Measure Editor Diagram 


Best practice: When reviewing the Business Measure Editor Diagram, it is 
helpful to maximize the diagram window (■'5 click the Maximize button in the 
upper right-hand corner of the window). Just ^ click the Restore button (in the 
upper right-hand corner of the window) to work with the Attribute view or the 
Project Tree view. 
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The Attributes view (described next), below the Business Measure Editor 
Diagram, is where the process or instance business measures are defined. You 
can associate business measures to the overall process or to individual activities 
within the process. The next two sections describe the business measures that 
can be defined. 

Process business measures 

When the Business Measure Editor Diagram is first opened, the Attributes view 
(below the diagram) displays process attributes rather than any element within 
the process. ^ Selecting any element within the diagram changes the focus of 
the Attributes view to that element. By ^ clicking anywhere on the diagram 
outside of a modeling element, the focus of the Attributes view returns to the 
overall process. You can define metrics, stopwatches, counters, and triggers for 
the process. As mentioned above, these business measures are not aggregated 
and apply to each individual instance of the process. 

Figure 18 displays the dialog for defining metrics associated with the process. 



Figure 18 Dialog for defining a process metric 
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Figure 19 displays the dialog for defining stopwatches associated with the 
process. 


'General 'x. Metric Stopwatch Counter Trigger Properties 
▼ Stopwatches 

This section provides information about stopwatches, which keep track of elapsed time. 
Stopwatch Name 


Event Type 


▼ Triggered actions 

This section provides information about triggers that affect the selected stopwatch. 

Trigger | Resulting actiorT 


Figure 19 Dialog for defining a process stopwatch 




v 


Figure 20 displays the dialog for defining counters associated with the process. 



Figure 20 Dialog for defining a process counter 

Figure 21 displays the dialog for defining triggers associated with the process. 
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Figure 21 Dialog for defining a process trigger 


Best practice: When working with the Attributes view, it is often more 
convenient to maximize the view (by ^ clicking the Maximize button in the 
upper right-hand corner of the view). By doing this, you can see and enter 
data in all the sections of the selected tab. Restore the view afterward for 
further work with the Business Measure Editor (by ^ clicking the Restore 
button in the upper right-hand corner of the view). 


Business measures for activities within the process 

The individual activities within a process can be ^ selected and be assigned 
business measures. The business measures are added to the appropriate tab 
within the Attributes view (usually below the diagram). 

Each time an activity is ' / 5 selected within the diagram, the focus of the Attributes 
view is set to that activity. 
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There are differences as to what type of business measures can be assigned to 
the types of modeling elements. Table 1 lists the types of process modeling 
elements and their available business measures. 

Table 1 Process modeling elements and their associated business measures 


Type of modeling element 

Type of business measure 

Start and End Nodes 

None 

Global and Local Tasks 

Trigger 

Local Process 

Metric, stopwatch, counter, trigger 

Global Process 

Business measure (a metric based on a 
metric, stopwatch, or counter of the target 
global process), trigger 

Loops 

Metric, stopwatch, counter, trigger 

Service 

Trigger 

Notification Broadcaster or Receiver 

None 

Timer, Observer, Map 

None 

All Flow Control Elements (Decisions, 
Fork, Join, Merge) 

None 


You can assign user-defined triggers to many of the types of activities within a 
process. These triggers react to a state change for the activity (for example, the 
start or completion) or to the input or output of a business item. These triggers 
can then be used to affect the behavior of other business measures within the 
process. 

Figure 22 displays the dialog for defining the triggers for activities within a 
process. 
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Figure 22 Dialog for defining a trigger on a process activity 

For global processes within your process, you can define triggers (as seen in 
Figure 22) and you can define metrics. These metrics are different from the 
metrics you define for the overall process (as seen in Figure 1 8 on page 31 ). The 
metrics for a global process capture the value of a metric that has already been 
defined in the reusable process that the global process modeling element 
represents. Therefore, you would have to use the predefined business measures 
or have previously defined business measures for the target process before you 
can define business measures for the global process. 

Figure 23 displays the dialog for defining the business measures (metrics) for a 
global process. 
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Figure 23 Dialog for defining a business measure for global process 

If you ^ select a compound activity in the Business Measure Editor Diagram, 
such as a local process or a loop, you can define metrics, stopwatches, and 
counters, as well as triggers (just like for the process as a whole). Basically, this 
is the same as opening up the diagram for the activity and defining business 
measures as shown in “Process business measures” on page 31. 


Business measures 

Business measures are the modeling elements that extend a process model to 
create a business measure model. These include situation events, triggers, 
counters, stopwatches, metrics, and KPIs. 

A business measure is a variable that describes the behavior of a particular 
business action that an employee, a process, or a business unit performs. 
Identifying and measuring the right variables are at the core of an effective 
measurement system. Managers can use this data to lead their organizations 
and make informed decisions. 

The development of business measures for a process or processes reflects 
management's decisions on the design of monitored dashboards (that reflect the 
organization’s goals and objectives), as well as the allocation of resources and 
the organization of the company. In addition, the design of the business 
measures is affected by the design of the business processes. Then, the 
management reaction to business measure (monitored) results will affect, in turn, 
the redesign of the processes. 
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Best practice: In WebSphere Business Modeler, it is easier to enter the 

relevant business measures by working bottom-up from events to KPIs in the 

following order: 

► Triggers (See Table 2 on page 39 for information to be captured for 
triggers.) 

► Counters based on triggers (See Table 3 on page 40 for information to be 
captured for counters.) 

► Stopwatches based on triggers (See Table 4 on page 42 for information to 
be captured for stopwatches.) 

► Metrics based on triggers (See Table 5 on page 43 for information to be 
captured for metrics.) 

► Metrics based on other metrics (See Table 6 on page 45 for information to 
be captured for aggregate metrics.) 

► KPIs (See Table 7 on page 47 for information to be captured for KPIs.) 

► Situation events (See Table 8 on page 50 for information to be captured 
for situation events.) 


The situation events are developed through the Project Tree by adding items to 
the business measure event catalog. The other elements will be entered through 
the Business Measure Editor, but first use the diagram to enter the triggers, 
counters, stopwatches, and non-aggregate metrics. 


Best practice: It does help to collect and organize all of the business measure 
information in a file, such as in an Excel spreadsheet (Figure 24). It may be 
more convenient to use a top-down approach for the initial capture of the 
business measure information, then add the bottom-up approach as described 
above, to enter the information in the tool. 


r — - 





| Process Activity Name 










Trigger Name 





Category 





Source 





Condition 










Figure 24 A section of business measure collection spreadsheet 
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The Business Measure Editor Diagram includes extra markers on the diagram to 
indicate when triggers, metrics, stopwatches, and counters have been added to 
the process model. In the diagram there is a business measure icon box in the 
upper left-hand corner. The box (Figure 25) displays the appropriate icons for 
triggers, metrics, stopwatches, and counters, respectively, as they are added to 
the process. 


@ EB 


Figure 25 Triggers, metrics, and counters defined for a process 

Triggers E* 

A trigger is added to a process model to detect an occurrence of an event and to 
initiate an action in response. For example, you could set a trigger to increment a 
counter each time a task ends. 

Triggers can detect any of the following occurrences: 

► A change of state of an activity. Each element, such as a task, has states 
such as start, stop, and suspend. 

► A change in a metric. 

► A change in a counter. 

► A specific time interval. 

► The arrival of an input (to a task or process). 

► The production of an output (of a task or process). 

The activation of a trigger, in turn, initiates the behavior of the other business 
measures that are defined to be dependent on it (for example, counters, 
stopwatches, metrics, and KPIs, as defined below). 

Remember that a process has a lot of built-in triggers that can be used for other 
business measures. These include all the state changes of activities (for 
example, starting, stopping), and the input or output of business items (to/from 
activities). 

Information about triggers is added within the Business Measure Editor using the 
Attributes view, as shown in Figure 21 on page 33 and Figure 22 on page 35. 


Best practice: Collect the following information about triggers (Table 2) in 
your business measure spreadsheet before entering in the Business Measure 
Editor. 
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Table 2 Trigger information 


(Optional) Process 
Activity Name 

The name of the process activity that contains the trigger. If none is named, then 
the trigger is for the process. 

Trigger Name 

The name of the trigger. 

Category 

The category can be one of these: 

► State change 

► Inputs and outputs 

► Recurring wait time 

► Metric 

► Counter 

Source 

The source depends on the category: 

► For state change: The source is a predefined trigger, such as the start of an 
activity. 

► For inputs and outputs: The source is the input or output criteria of the 
process. 

► For recurring wait time: The source is a user-defined duration. 

► For metric: The source is a user-defined metric for the process. 

► For counter: The source is a user-defined counter for the process. 

(Optional) 

The condition is an expression (through the expression builder) that must be 

Condition 

true, in addition to the source, before the trigger is activated. 

(Optional) Situation 
Event(s) 

A user-defined business measure event that is emitted when the trigger occurs. 

(Optional) Attribute 

Each attribute can have a calculation expression defined (through the 

Calculation 

expression builder). 

Event Sending 

Each situation event will occur: 

► Only once 

► Every time 

(Optional) Situation 

The condition is an expression (through the expression builder) that must be 

Event Condition 

true, before the situation event is activated. 


Triggers can be associated with processes or the activities with a process (tasks, 
local processes (including loops), global processes, and services) by “'b selecting 
the activity and then adding the trigger on the Trigger tab of the activity’s 
attributes. The Business Measure Editor Diagram displays the Trigger icon 
above the activity (Figure 26) or within the business measure icon box (Figure 25 
on page 38). 
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Figure 26 A trigger defined for a task 

Counters E! 

In general, counters are used to keep track of the frequency of a specific event’s 
occurrence. They can be increased by one, decreased by one, or set to zero by 
triggers. You can use a counter to track, for example, the number of times a task 
was started within a process where the task is contained in a loop. Counters can 
be used to measure numbers within one run of the process, but you can reuse 
them within a KPI or aggregate metric to determine the average, maximum, 
minimum, or total across multiple runs of the process and then display the 
information on a dashboard. 

Information about counters is added within the Business Measure Editor using 
the Attributes view, as shown in Figure 20 on page 32. 



Best practice: Collect the following information about counters (Table 3) in 
your business measure spreadsheet before entering in the Business Measure 
Editor. 


Table 3 Counter information 


Counter Name 

The name of the counter. 

Source Trigger(s) 

A trigger associated with a process event, such as the completion of an activity. 
The trigger determines when the value of the counter is updated, as determined 
by the specified action. 

Action(s) 

Each trigger has a single action of these types: 

► Add one. 

► Subtract one. 

► Set to zero. 

(Optional) Situation 
Event(s) 

A user-defined business measure event that is emitted when the trigger occurs. 

(Optional) Attribute 
Calculation 

Each attribute can have a calculation expression defined (through the 
expression builder). 
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Event Sending 

Each situation event will occur: 


► Only once 


► Every time 

Situation Event 

The condition is an expression (through the expression builder) that must be 

Condition 

true, before the situation event is activated. 


Counters can be associated with processes or for local processes (including 
loops). The Business Measure Editor Diagram displays the Counter icon above 
the activity (Figure 27) or within the business measure icon box (Figure 25 on 
page 38). The source trigger(s) for the counters belong to that process or for 
activities within that process, including sub-activities contained within a local 
process. The triggers defined in a parent process (a higher level process) are not 
available, however. 


01 



£ 

Auto Claims 
Verification 


\ 



Figure 27 A counter defined for a local process activity 

Stopwatches 

You can use a stopwatch to track the elapsed time since a request was sent, for 
example, or the time since the claim process started. Stopwatches can be used 
to measure durations within one run of the process, but you can reuse them 
within a KPI or aggregate metric to determine the average, maximum, minimum, 
or total duration across multiple runs of the process. 

Stopwatches can be started, stopped, and reset by specific triggers that you 
define. When you start a stopwatch, it begins to count the elapsed time. When 
you stop the stopwatch, it stops counting and keeps its value. If you start the 
stopwatch again, it begins counting by adding to the previous stored value. If you 
reset the stopwatch, it sets the value to zero and stops. 

Information about stopwatches is added within the Business Measure Editor 
using the Attributes view, as shown in Figure 19 on page 32. 
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Best practice: Collect the following information about stopwatches (Table 4) 
in your business measure spreadsheet before entering in the Business 
Measure Editor. 


Table 4 Stopwatch information 


Stopwatch Name 

The name of the stopwatch. 

Trigger(s) 

A trigger associated with a process event, such as the completion 
of an activity. The trigger determines when the stopwatch is 
updated, as determined by the specified action. 

Action(s) 

Each trigger has a single action of these types: 

► Start. 

► Stop. 

► Reset. 


Stopwatches can be associated with processes or for local processes (including 
loops). The Business Measure Editor Diagram displays the Stopwatch icon 
above the activity (Figure 28) or within the business measure icon box (Figure 25 
on page 38). The source trigger or triggers for the counters belong to that 
process or for activities within that process, including sub-activities contained 
within a local process. The triggers defined in a parent process (a higher level 
process) are not available, however. 
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Figure 28 A stopwatch defined for a local process activity 

Metrics ™ 

Metrics are mechanisms for capturing relevant information about a business 
process or business system. For WebSphere Business Modeler, a metric is a 
measurement of a process or process element that is used to assess business 
performance. It can have numeric values such as the duration of a process, or 
non-numeric values such as the delivery dates of shipments. A metric can be 
used alone or in combination with other metrics to define the calculation for a 
KPI, which measures performance against a business objective across multiple 
process instances. A metric is defined within a specific process using 
WebSphere Business Modeler, and the value of that metric is captured and 
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evaluated using WebSphere Business Monitor. Examples of business metrics 
are a supplier’s average response time and the cost of the risk assessment step 
in an insurance process. 

Metrics can optionally generate situation events that can cause business actions. 
An administrator uses the Action Manager in WebSphere Business Monitor to 
specify what happens when the situation event is received. 


Best practice: When developing metrics, you should consider the following: 

► What is the purpose of the metric? 

► Do you want the metric to show up in Monitor’s dashboard? 

► Will the metric be used to take an action? If so, then a situation event is 
required. 

► Is aggregation needed? If so, see “Aggregate metrics ” on page 44. 

► If aggregated, does the aggregate metric have a target or limits? Then it 
becomes a KPI (see “KPIs ” on page 46). 


Information about metrics is added within the Business Measure Editor using the 
Attributes view, as shown in Figure 18 on page 31. 


Best practice: Collect the following information about metrics (Table 5) in your 
business measure spreadsheet before entering in the Business Measure 
Editor. 


Table 5 Metric information 


Metric Name 

The name of the metric. 

Metric Data Type 

String, Integer, etc. 

Description 

A user-defined text description of the purpose of the metric. 

Trigger 

A trigger associated with a process event, such as the completion of an activity. 
The trigger determines when the value of the metric is updated, as determined 
by the specified calculation. 

Calculation 

A user-defined expression (through the expression builder) that determines 
how the value of the metric will be determined. The calculation may be simple 
by taking the value of an attribute of a modeling element (for example, an 
activity, business item, or another metric) or may involve an operation between 
two modeling elements. 

(Optional) Situation 
Event(s) 

A user-defined business measure event that will be emitted when the trigger 
occurs. 
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(Optional) Attribute 

Each attribute can have a calculation expression defined (through the 

Calculation 

expression builder). 

Event Sending 

Each situation event will occur: 


► Only once 


► Every time 

Situation Event 

The condition is an expression (through the expression builder) that must be 

Condition 

true, before the situation event will be activated. 


Metrics can be associated with processes or for local processes (including 
loops). The Business Measure Editor Diagram will display the Metric icon above 
the activity (Figure 29) or within the business measure icon box (Figure 25 on 
page 38). The source trigger or triggers for the counters belong to that process or 
for activities within that process, including sub-activities contained within a local 
process. The triggers defined in a parent process (a higher level process) are not 
available, however. 



Figure 29 A business measure (metric) defined for a global process activity 


Aggregate metrics ™ 

A calculation of a standard metric is applied separately to each instance of the 
process that is run by the WebSphere Process Server. Aggregate metrics, on the 
other hand, are calculated across multiple runs of the process, for finding the 
average, maximum, minimum, or total number of occurrences. These types of 
metrics, and KPIs, are used to measure performance on WebSphere Business 
Monitor dashboards. 


If you created a standard Revenue Minus Cost metric, for example, it would 
calculate the revenue and subtract the cost for each process run for a net value. 
To get an average net value you could have an Average Revenue Minus Cost 
aggregate metric defined with a function to average the aggregate net value for 
the Revenue Minus Cost metric across multiple runs of the process. 
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Best practice: When developing aggregate metrics, you should consider the 
following: 

► What is the purpose of the metric? 

► Will the metric be used to take an action? If so, then a situation event is 
required. 

► Does the metric have a target or limits? Then define a KPI instead (see 
“KPIs ” on page 46). 

► Do you want the value to appear on Monitor dashboards? If so, define a 
KPI instead (see “KPIs ” on page 46). 


Information about aggregate metrics is added within the KPIs and Aggregate 
Metrics tab of the Business Measure Editor using the Attributes view, as shown 
in Figure 16 on page 29. 


Best practice: Collect the following information about aggregate metrics 
(Table 6) in your business measure spreadsheet before entering in the 
Business Measure Editor. 


Table 6 Aggregate metric information 


Aggregate Metric 
Name 

The name of the metric. 

Metric Data Type 

Float, Integer, etc. 

Aggregation Function 

The types of functions are: 

► Total 

► Average 

► Minimum 

► Maximum 

► User-defined 

Aggregation Source 

For functions total, average, minimum, and maximum: 

► Counters, metrics, and stopwatches that have been defined for the 
process 

For a user-defined function: 

► An expression (through the expression builder) 

(Optional) Situation 
Event(s) 

A user-defined business measure event that is emitted when the metric occurs. 

(Optional) Attribute 

Each attribute can have a calculation expression defined (through the 

Calculation 

expression builder). 
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Event Sending 

Each situation event will occur: 


► Only once 


► Every time 

Situation Event 

The condition is an expression (through the expression builder) that must be 

Condition 

true, before the situation event is activated. 


For aggregate metrics, there is no graphical icon on the Business Measure Editor 
Diagram to show that any aggregate metrics have been defined. 

KPIs 

A key performance indicator (KPI) is just that — an important indicator of how well 
a process or an organization is performing. The most effective KPIs are based on 
strategic goals. A strategic goal is an executive statement of direction in support 
of a corporate strategy. The strategic goal is a high-level goal that is quantifiable, 
measurable, and results-oriented. For business measures modeling, the 
strategic goal is translated into a KPI that enables the organization to measure 
some aspect of the process against a target that they define. KPIs are defined 
within the context of the Business Measures Editor and evaluated by WebSphere 
Business Monitor, comparing the defined KPI targets against actual results to 
determine levels of success. 

A KPI is associated with a specific process and is generally represented by a 
numeric value, based on one or more metrics. A KPI does have a target and 
allowable margins (percentage of target), or lower and upper limits (absolute 
values), forming a range of performance that the process should achieve. An 
example of a simple KPI is average time for response to a customer inquiry, with 
a target of less than two days. 

KPIs, as well as metrics and counters, can optionally generate situation events 
that can cause business actions. An administrator can use the Action Manager in 
WebSphere Business Monitor to specify what happens when the situation event 
is received, such as an e-mail notification to the appropriate person. 

Information about KPIs is added within the KPIs and Aggregate Metrics tab of the 
Business Measure Editor using the Attributes view, as shown in Figure 15 on 
page 29. 


Best practice: Collect the following information about KPIs (Table 7) in your 
business measure spreadsheet before entering in the Business Measure 
Editor. 
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Table 7 KPI information 


Strategic Goal 

The strategic goal that is the driver for developing the KPI (not captured 
within WebSphere Business Modeler). 

KPI Name 

The name of the KPI. 

KPI Data Type 

Float, Integer, etc. 

Aggregation Function 

The types of functions are: 

► Total 

► Average 

► Minimum 

► Maximum 

► User-defined 

Aggregation Source 

For functions total, average, minimum, and maximum: 

► Counters, metrics, and stopwatches that have been defined for the 
process 

For a user-defined function: 

► An expression (through the expression builder) 

Use Target 

A check box that sets whether a target is used. If there is to be no target, then 
the target information is not used, but the limits are used. If there is to be a 
target, then the target information is used, but the limit information is not 
used. 

Target 

A value that sets the desired value for the KPI. 

Lower Target Margin (%) 

This is set as a percentage. The calculation of the lower limit based on the 
lower target margin (Itm) is: 
target - (target * ltm) 

Upper Target Margin (%) 

This is set as a percentage. The calculation of the upper limit based on the 
upper target margin (utm) is: 
target + (target * utm) 

Lower Limit 

A value that sets the lower limit for the range of safe KPI values. 

Upper Limit 

A value that sets the upper limit for the range of safe KPI values. 

(Optional) Situation 

A user-defined business measure event that is emitted when the metric 

Event(s) 

occurs. 

(Optional) Attribute 

Each attribute can have a calculation expression defined (through the 

Calculation 

expression builder). 

Event Sending 

Each situation event will occur: 

► Only once 

► Every time 

Situation Event 

The condition is an expression (through the expression builder) that must be 

Condition 

true, before the situation event is activated. 
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For KPIs, there is no graphical icon on the Business Measure Editor Diagram to 
show that any KPIs have been defined. 


Best practice: When defining KPIs, be consistent in the use of targets and 
margins or limits. Dashboard views do not allow the mixing of limits and 
targets with margins, so it would be best to choose one mechanism for all 
KPIs. 


Best practice: The Scorecard view requires the use of targets and margins, 
so they are usually a better choice than limits. 


Good KPIs 

Every company's center of success lies in its ability to provide better products, 
services, or both in the shortest time and for the minimum cost. Appropriate 
business measurement makes process improvement not only possible but also 
continuous. Employees tend to reduce the complexity of these activities, which 
leads to decreasing costs while increasing productivity and flexibility. 

Thus, it is important to use business measures effectively to drive performance 
improvements. A measurement system only provides you with data. It has value 
only if the data can be used to make good business decisions and to drive 
improvement efforts that translate into appropriate actions and performance 
plans. 

The development of appropriate KPIs helps to focus on the runtime management 
of the process and also guides the directions for improving (remodeling) the 
processes, which is a key benefit of the Business Innovation and Optimization 
lifecycle. 
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Best practice: The following are essential characteristics of effective KPIs: 

► Represent the essential few: A successful set of measures contains the 
vital few key measures that are linked to your success. There may be 
hundreds, or even thousands, of measures in your organization's 
database, but no individual can focus on more than a few relevant 
measures. 

► Combine multiple measures into several overall business measures: 

A number of organizations struggle with measuring performance by looking 
at a dozen or so measures. One way of reducing the number of measures 
is to assign a weight to each measure in a family of measures. You can 
develop an index, or an aggregate statistic, that represents performance by 
multiplying each measure by its assigned weight and then adding all such 
products to arrive at a weighted-average total. 

► Change your strategy as situations change: Sometimes a company 
starts collecting data on a specific measure because of a specific problem. 
Once the problem has been solved or the issues that caused the problem 
have disappeared, collecting, analyzing, and reporting the measure may 
be unnecessary. 

► Quantify how well processes achieve their goals: A business measure 
is defined as a quantification of how well the activities within a process or 
the outputs of a process achieve a specified goal. Quantification is an 
important part of this definition. To measure something, its attributes must 
be quantified. Measurement requires the act of measuring and should 
therefore be reliable and repeatable. 


All this leads to the conclusion that the core of an effective measurement system 
is its set of business measures and how well they are chosen. To this end, the 
KPI should be put into a context of what the process or organization is trying to 
accomplish, which is identified by the goals and targets that have been defined. 
Therefore, a good KPI should be designed to help determine whether or not a 
goal or objective is being satisfied. 

Situation events ' 

Situation events are generated when a business situation arises, such as a 
printer running out of paper or an ATM running out of cash. Other business 
situations could be an unacceptable customer response time or a declining sales 
count that has dropped below a predefined threshold. The WebSphere Business 
Monitor administrator uses the Action Manager to specify what happens when 
the situation event is received. An alert can be displayed in the Alerts view, or a 
message or e-mail can be sent to notify the appropriate person to take action. 
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Metrics, KPIs, counters, and triggers can all optionally generate situation events 
that can cause business actions. To define situation events, create a business 
measure event category in the Project Tree (you might have to remove the 
Process Tree filter first). Then add the event definitions to the business measure 
event category. Once created, the events are available to be associated with a 
business measure. 

Information about situation events is added within the Event Definition Editor 
using the Attributes view, as shown in Figure 21 on page 33 and Figure 22 on 
page 35. 


Best practice: Collect the following information about triggers (Table 8) in 
your business measure spreadsheet before entering in the Business Measure 
Editor. 


Table 8 Situation event information 


Situation Event Name 

The name of the situation event. 

Event Type 

Business Situation Event, or Common Base Event. 

(Optional) Attribute(s) 

You can add new attributes to the event type. 

Name 

The attribute name. 

Type 

The attribute type (String, Integer, etc.). 

Minimum 

Minimum occurrences for the attribute. 

Maximum 

Maximum occurrences for the attribute. 

Container 

Each situation event container is a: 

► Extended data element 

► Context data element 


After a situation event has been defined, it is available for being associated with 
the other business measures (for example, triggers, counters, stopwatches, 
metrics, and KPIs). However, there is no graphical icon on the Business Measure 
Editor Diagram to show that it has been defined. 

Dimensional analysis settings 

Dimensional analysis allows you to aggregate metrics over different dimensions 
so that you can analyze historical information at various levels of detail, allowing 
you to detect trends that may not otherwise be obvious. 
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For example, if you have collected a lot of data, such as the sales figures for 
every product your company makes, you should be able to retrieve information 
from this data and find answers to questions like these: 

► What are the total sales for each product by location? 

► Which products are selling best over time? 

To be able to perform dimensional analysis in the Dimensions view of 
WebSphere Business Monitor, you must specify information in the business 
measures model that is used to create a dimensional model at deployment time. 

These are the basic steps in setting up dimensional analysis for the WebSphere 
Business Monitor (it is best done in this order): 

1 . Define the dimensions (for example, location, product type). 

These are labels for the categories that will organize the WebSphere 
Business Monitor results. To define a dimension, open the Business Measure 
Editor Diagram and ^ click anywhere outside of a modeling element (on the 
white space). “'B Select the General tab of the Attributes view. Click Addin 
the Dimensions section of the view and \Sk modify the name of the dimension 
(Figure 30). 
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Figure 30 Defining the dimensions 

2. Create business item metrics to be used for dimensional analysis. 

You require two types of metrics for the dimensional analysis: 

- The first type of metric defines the source of the quantitative data that is to 
be aggregated (the actual numbers, for example, the total sales amount). 

- The second type of metric defines the source of the categories for the 
dimensions. For example, if the dimension was Location , then you would 
define one metric for countries and another metric for cities. 
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To add the business item metrics, “?) right-click the white space of the 
Business Measure Editor Diagram and ^ select Create Business Item Metric 
from the menu. A dialog box (Figure 31) opens to select the appropriate 
business item from the input and output criterion of the process. 



Figure 31 Selecting a business item for the metric 

3. Set up the dimensional analysis options for the business item metrics. 

After you have defined the appropriate business item metrics, you have to 
define how they are used in the dimensional analysis performed by the 
WebSphere Business Monitor in the Dimensions view (see “Dimensions view” 
on page 78). The quantitative and category types of business item metrics will 
have different settings. 

To define the dimensional analysis settings, open the Business Measure 
Editor Diagram and ^ click anywhere outside of a modeling element (on the 
white space). Select the Metric tab of the Attributes view. The dimensional 
analysis settings are at the bottom of the view (Figure 32). 
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This section provides details about how the selected business measure will be represented in the dimensional analysis view of WebSphere Business Monitor and in the database 


Usage in WebSphere Business Monitor Aggregation group in dimensional analysis ▼ 

[~~1 Create index to optimize database performance for sorting based on this measure in WebSphere Business Monitor 

Iffl 


Maximum string length 
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PI Set as part of dimension key 

Dimension | Location ▼ 

Aggregation group level 1 0 



Figure 32 Defining dimensional analysis data 
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Best practice: When defining dimensional analysis data, it is more 
convenient to maximize the Attributes view. By doing this, you can see and 
enter data in the Metrics and Dimensional analysis and database schema 
settings sections of the Metric tab. You could collapse the Situation Events 
section in order to see more of the view information. Restore the view 
afterward for further work with the Business Measure Editor. 


For the metrics used for quantitative aggregation, the settings are: 

► Usage: Quantitative data in dimensional analysis. 

► Aggregation measures also have to be defined:. 

You can aggregate in more than one way for the same data. For example, for 
a business item metric such as Order Amount, you might want to display the 
total amount and the average amount. For this situation, you would set up two 
aggregation measures, one that sums the data and one that averages the 
data. 

For the metrics used for aggregation groups, the settings are: 

► Usage: Aggregation group in dimensional analysis. 

► (Si Set maximum string length (usually 50, based on your business items). 

► Allocate additional space. 

► Set as part of dimension key. 
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► ^ Select the dimension (as was defined is step 1 above). 

► (Sb Set the aggregation level. Level 0 is the default and the first level. 
Additional levels (1 and higher) are used to further drill down into the data. For 
example, for the Location dimension, Country would be the first level (level 0). 
Then you would drill down into the City (level 1). 


Examples 

The two examples, Verify Account (from the fictional JK Enterprises) and Handle 
Order (from the fictional ClipsAndTacks, Inc.), are continued to illustrate 
business measures in the following two sub-sections. 

Verify Account process 

JK Enterprises' high-level business objective is to improve customer satisfaction. 
Specifically, management wants to achieve the following goals: 

► The percentage of new account applications that take longer than a day 
should be less than 14.5%. 

- Thus, a KPI was developed to measure the percentage of process 
durations that exceeded one day, which included a target set for 14.5%. 

- A related KPI was developed to track the average duration for processing 
a new account application. 

► The next two sections describe the business measures that lead to the KPIs 
for the Verify Account process. 

Percentage of accounts exceeding one day 

There are two sets of business measures that lead to the calculation of the 
Percent Applications Exceeding Max Duration KPI. The next three sub-sections 
describe these business measures plus the KPI itself. 

► Catching the application durations that exceed 8 hours 

First, a trigger has to be defined to catch any process duration that exceeds 8 
hours. The trigger is defined by opening the Business Measure Editor 
Diagram, clicking any white space of the diagram (to set the focus to the 
process and not any activity within the process), ^ selecting the Trigger tab 
of the Attributes view, and then adding the information. The data collected for 
the trigger can be found in Table 9. 


Table 9 Trigger to capture process duration 


Process Name 

Verify Account 

Trigger Name 

Elapsed Duration Greater than 8 Hours Trigger 


54 


Best Practices for Using WebSphere Business Modeler and Monitor 




Category 

State Change 

Source 

Process State Completed for Verify Account process 

Condition 

'Process Elapsed Duration Timer 1 is greater than 8 hours 


The intent is for the trigger to only occur if the elapsed duration of the process 
is greater than 8 hours (1 day) after it has completed. Thus, a condition 
expression has to be defined for the trigger. To define the condition, ^ click 
Edit, which is on the right side of the view below the reusable triggers section. 
This opens the Expression Builder dialog (Figure 33). 



Figure 33 Defining the condition expression for the trigger 
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The first term of the expression is a Modeling artifact, for which we “?) select 
Process Elapsed Duration. For the operator between the two terms we select 
is greater than. For the second term we select the type Duration , and we is 
set the value to 8 hours. Once applied, the expression appears in the 
Expression text box (in the center right of the dialog box). 

After the trigger has been defined, a Trigger icon is displayed in a small box in 
the upper left of the diagram (Figure 34). 


*{► ira E3 


Figure 34 Trigger icon (far left) for the Verify Account process 

Next, a counter is required to count the number of times the Application 
Duration Exceeds 8 Hours Trigger occurs. For any given execution of the 
process, the counter has either have a value of zero (0) or one (1). An 
aggregate metric, as defined below, will aggregate the number over the 
executions of the process. 

The counter is defined by opening the Business Measure Editor Diagram, “?) 
clicking any white space of the diagram, ' y 6 selecting the Counter tab of the 
Attributes view, and then adding the information. The data collected for the 
counter can be found in Table 10. 


Table 10 Counter for the Verify Account process 


Process Name 

Verify Account 

Counter Name 

Application Duration Exceeds 8 Hours Counter 

Source Trigger(s) 

User defined trigger: Elapsed Duration Greater than 8 Hours 
Trigger 

Action(s) 

Add one 


► Counting the total number of applications 

The application duration will not exceed 8 hours every time (and, hopefully, 
not very often). But to know the percentage of times the duration is too long, 
we have to know the total number of applications that are processed to 
compare with the number that has a duration longer than 8 hours. The 
business measure for the total number is a fairly simple business measure to 
define. The data collected for the counter can be found in Table 1 1 . 
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Table 11 Counter for number of applications 


Process Name 

Verify Account 

Counter Name 

Applications Processed Counter 

Source Trigger(s) 

Predefined trigger: Process State Completed 

Action(s) 

Add one 


This counter does not utilize a user-defined trigger, but instead uses a 
predefined trigger, available to all processes. In this case, the completion of 
the process is the trigger. To define this type of predefined trigger for the 
counter, ^ select Add new trigger (radio button) within the Select Trigger 
dialog box (Figure 35). Then ^ select the source category (in this case, State 
change). Then ^ select the source. 



Figure 35 Selecting a predefined trigger 

To select the source of the predefined trigger, the Select State Transition 
Event dialog is used (Figure 36). 

You can select one of the predefined triggers for the process or one of the 
activities in the process. In this case, Process State Completed is selected. 
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Select State Transition Event 

(T) Select the trigger elements 


/ 

Tree Name 

Process State Created 
Process State Started 
laj* Process State Restarted 
Process State Suspended 
Process State Resumed 


[Process State Completed 


Process State Terminated 

+ © Account Verification (To-Be)_Determine Applicant Eligibility 
+ © Account Verification (To-Be)_Initial Application Review 
+ Account Verification (To-Be)_Credit Report Service - Electronic 
+ Account Verification (To-Be)_Credit Assessment Business Rule 
+ © Account Verification (To-Be)_Request More Documentation 
+ © Account Verification (To-Be)_Final Application Review 
® © Account Verification (To-Be)_Generate Decline 
+ © Account Verification (To-Be)_Provide Pricing & Approval 


/ 

OK | Cancel 


Figure 36 Selecting a predefined state change trigger 

The Application Processed Counter is incremented by one for every Verify 
Account process executed. Then the counter is used in an aggregate metric 
to keep track of the total number of applications processed. 

► Creating the KPI 

Before determining the percentage, the aggregate metrics based on the 
Application Duration Exceeds 8 Hours Counter and the Applications 
Processed Counter must be defined. An aggregate metric is defined by 
opening the Business Measure Editor, “Hi selecting the K Pis and Aggregate 
Metrics tab, “ti selecting Aggregate Metric in the Business Measure tree, and 
then adding the information. The data collected for the first aggregate metric 
can be found in Table 12. 


Table 12 First aggregate metric for the Verify Account process 


Process Name 

Verify Account 

Aggregate Metric Name 

Total Applications Exceeding Max Duration 

Metric Data Type 

Integer 

Aggregation Function 

Total 

Aggregation Source 

Application Duration Exceed 8 Hours Counter 
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The second aggregate metric collects the data from the Applications 
Processed Counter. The data collected for the aggregate metric can be found 
in Table 13. 


Table 13 Second aggregate metric for the Verify Account process 


Process Name 

Verify Account 

Aggregate Metric Name 

Total Applications Processed 

Metric Data Type 

Integer 

Aggregation Function 

Total 

Aggregation Source 

Applications Processed Counter 


After the two aggregate metrics have been defined, the Percent Applications 
Exceeding Max Duration KPI can be defined. The KPI is defined by opening 
the Business Measure Editor, ^ selecting the KPIs and Aggregate Metrics 
tab, ^ selecting KPIs in the Business Measure tree, and then adding the 
information. The data collected for the KPI can be found in Table 14. 


Table 14 Percent Applications Exceeding Max Duration KPI 


Process Name 

Verify Account 

KPI Name 

Percent Applications Exceeding Max Duration 

KPI Data Type 

Double 

Aggregation Function 

User-defined (expression) 

Aggregation Source 

Metric: Total Applications Exceeding Max Duration 

/ 

Metric: Total Applications Processed 

Use Target 

True 

Target 

14.5% 

Lower Target Margin (%) 

30% (= 10.15%) 

Upper Target Margin (%) 

2% (= 14.79%) 


Since the KPI reflects a percentage, it requires the calculation of an 
expression that utilizes the two aggregate metrics defined above. This 
expression, like the trigger condition defined earlier, is defined using the 
Expression Builder dialog (Figure 37). 
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Figure 37 Defining a KPI expression 


The first term of the expression is a Modeling artifact, where you “'5 select the 
Total Applications Exceeding Max Duration aggregate metric. The operator 
between the two terms is a slash (/). The second term is of type Modeling 
artifact, and you ^ select the Total Applications Processed aggregate metric. 

With these definitions, the Percent Applications Exceeding Max Duration KPI 
is now ready to be used within the WebSphere Business Monitor. 

Average Account Opening Duration 

The Average Account Opening Duration KPI does not require preliminary 
business measures to be set up. This simple KPI can be defined directly with the 
collected data and with a predefined stopwatch. The data collected for the KPI 
can be found in Figure 15. 


Table 15 Average Account Opening Duration KPI 


Process Name 

Verify Account 

KPI Name 

Average Account Opening Duration 

KPI Data Type 

Duration 
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Aggregation Function 

Average 

Aggregation Source 

Predefined stopwatch: Process Elapsed Duration 

Use Target 

True 

Target 

8 hours 

Lower Target Margin (%) 

40% (= 4.8 hours) 

Upper Target Margin (%) 

5% (= 8.4 hours) 


When selecting the source for the KPI, you can select user-defined and 
predefined counters, metrics, and stopwatches (Figure 38). In the case of this 
KPI, the Process Elapsed Duration is ^ selected. 


Source Business Measures 


Business measures 


-qa Counters 

m Application Approved Counter 
G0 Application Duration Exceeds 8 Hours Counter 
PTH Application Processed Counter 
E3 Application Rejected Counter 

- Metrics 

jwrj Account Opening Cost 
jwrj Credit Extended Metric 

jwrj Credit Report Service - Electronic Task Cost Metric 
jwrj Final Application Review Task Cost Metric 
rH Generate Decline Task Cost Metric 
H Initial Application Review Task Cost Metric 
rH Process Duration 

W Provide Pricing & Approval Task Cost Metric 
W Request More Documentation Task Cost Metric 

- C7j Stopwatches 




fa 


Process Elapsed Duration 


V 


Cancel 


Figure 38 Selecting a business measure source for a KPI 


Handle Order process 

ClipsAndTacks' business objectives at their highest level are to increase revenue 
and reduce costs. Specifically, management wants to achieve the following 
goals: 

► Reduce the average time from when orders are received to the time they are 
shipped (to 3 days or less). 
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Thus, a KPI was developed to measure the duration for processing an order, 
which included a target set for 3 days. 

The simulation results (see “Simulation ” on page 22) showed an average 
duration of over 6 days. But this was with one shipper for the process. After 
the simulation was conducted it was decided to use two shippers for the 
actual process. 

► Increase the percentage of approved orders to 90%. 

Thus, a KPI was developed to measure the percentage of orders approved, 
which included a target set for 90%. 

The next two sections describe the business measures that lead to the KPIs for 
the Handle Order process. 

Duration for processing an order 

To help with the previous goal, a second goal was defined that takes a closer 
look at how the process works. 

To capture how long it takes to process an order after it has been placed, with 
the redesigned process, the duration of interest to be measured is a section of 
the process rather than just the duration of the whole Handle Order process. The 
reusable sub-process Receive Order is not considered to be part of the time the 
management is interested in improving (at least for this process). Therefore, the 
section of the process of interest starts with the starting of the Check Order 
Handling Policy for Automatic Approval task and ends with the completion of the 
Ship Order to Customer task. Thus, instead of using the predefined Process 
Elapsed Duration stopwatch, specific metrics have to be set up. 

First, a trigger has to be defined for the Check Order Handling Policy for 
Automatic Approval task, since this represents the start of the duration for the 
section of the process. The trigger is defined by opening the Business Measure 
Editor Diagram, “'9 selecting the task, ^ selecting the Trigger tab of the 
Attributes view, and then adding the information. The data collected for the 
trigger can be found in Table 16. 


Table 1 6 Trigger for Check Order Handling Policy for Automatic Approval task 


Process Name 

Handle Order 

Trigger Name 

Check Order Handling Policy Trigger 

Category 

State Change 

Source 

Activity State Started for Check Order Handling Policy for Automatic 
Approval task 
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After the trigger has been defined, a Trigger icon is displayed above the task 
(Figure 39). 


\ 

© 

Check Order 
Handling Policy 
for Automatic 
Approval 


Figure 39 Trigger icon for the Check Order Handling Policy for Automatic Approval task 

Another trigger has to be defined for the Ship Order to Customer task, since the 
completion of this task represents the end of the duration of the section of the 
process. The data collected for the trigger can be found in Table 17. 


Table 1 7 Trigger for the Ship Order to Customer task 


Process Name 

Handle Order 

Trigger Name 

Ship Order Trigger 

Category 

State Change 

Source 

Activity State Completed for Ship Order to Customer task 




After the trigger has been defined, a Trigger icon is displayed above the task 
(Figure 40). 



© 

Ship Order 
to Customer 


2 > 


BIJ Product 
j<\ Packing Slip 


Figure 40 Trigger icon for the Ship Order to Customer task 


Note: The predefined triggers for the start of the Check Order Handling Policy 
task and the completion of the Ship Order to Customer task could have been 
used for the metrics to be defined below. However, by explicitly defining these 
triggers, which results in the Trigger icons displayed on the Business Measure 
Editor Diagram, it is easier for WebSphere Business Modeler users to 
understand the intent of the business measure model. 
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The examples below use both the predefined and user-defined Triggers to show 
how they might be used. Figure 41 displays a Business Measure Editor Diagram 
of the Handle Order process. The figure includes a box surrounding the activities 
that make up the section of the process that determines the metric for the time it 
takes to handle an order. The two tasks at each end of the box have the Trigger 
icon above them to demark the boundaries of the process section within 
WebSphere Business Modeler. 



Figure 4 1 The section of the process measured for order handling duration 

After the triggers are defined, we create two metrics used to capture the time and 
date of when the triggers occur. The first metric captures the start of the order 
handling section of the process. The metric is not an aggregate metric; therefore 
it is defined by opening the Business Measure Editor Diagram, ^ clicking any 
white space in the diagram (to set the focus to the process and not any activity 
within the process), selecting the Trigger tab of the Attributes view, and adding 
the information. The data collected for the metric can be found in Table 18. 


Table 18 First metric for the Handle Order process 


Process Name 

Handle Order 

Metric Name 

Check Order Handling Policy Metric 

Metric Data Type 

DateTime 

Description 

A metric to capture the time and date of the start of the Check 
Order Handling Policy task, based on the defined trigger. This 
metric is used in the calculation of the order handling duration 

Trigger 

Predefined Trigger: Activity State Started for the Check Order 
Handling Policy task 
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Calculation 

The value of a predefined metric: Activity Start Time for the Check 


Order Handling Policy task 


The second metric captures the completion of the order handling section of the 
process. The data collected for the metric can be found in Table 19. 


Table 19 Second metric for the Handle Order process 


Process Name 

Handle Order 

Metric Name 

Order Shipped Metric 

Metric Data Type 

DateTime 

Description 

A metric to capture the time and date of the completion of the Ship 
Order to Customer task, based on the defined trigger. This metric 
is used in the calculation of the order handling duration 

Trigger 

Predefined Trigger: Activity State Completed for the Ship Order to 
Customer task 

Calculation 

The value of a predefined metric: Activity Complete Time for the 
Ship Order to Customer task 


A third metric is required to calculate the duration between the start and the 
completion of the section of the process. The data collected for the metric can be 
found in Table 20. Note that the activation of one metric can serve as a trigger in 
another metric (as shown in this example). 

Table 20 Third metric for the Handle Order process 


Process Name 

Handle Order 

Metric Name 

Process Duration Metric 

Metric Data Type 

Duration 

Description 

A metric to calculate the difference between the Order Shipped 
Metric and the Check Order Handling Policy Metric 

Trigger 

User-defined trigger: activation of the Order Shipped Metric 

Calculation 

Order Shipped Metric - Check the Order Handling Policy Metric 


Finally, to relate back to the original goal of reducing the order processing time to 
three days, a KPI has to be defined. This KPI calculates the aggregate of the 
Process Duration Metric (defined above) and apply the three-day target, with 
margins. 
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The KPI is defined by opening the Business Measure Editor, ^ selecting the 
KPIs and Aggregate Metrics tab, ^0 selecting KPIs in the Business Measure tree, 
and then adding the information. The data collected for the KPI can be found in 
Table 21 . 

Table 21 Defining the Average Order Fulfillment KPI 


Process Name 

Handle Order 

Strategic Goal 

Reduce the amount of time it takes to ship an order to 
three days or less 

KPI Name 

Average Order Fulfillment 

KPI Data Type 

Duration 

Aggregation Function 

Average 

Aggregation Source 

Process Duration Metric 

Use Target 

True 

Target 

3 days 

Lower Target Margin (%) 

66.7% (= 1 day) 

Upper Target Margin (%) 

0% (= 3 days) 


Percentage of orders approved 

To determine the percentage of orders approved, the same two triggers that 
were just defined can be used (Table 16 on page 62 and Table 17 on page 63). In 
addition to triggering the metrics defined above, they also trigger two counters. 

The first counter counts the number of times the Check Order Handling Policy 
task starts, as signified by the defined trigger. The counter is defined by opening 
the Business Measure Editor Diagram, ^0 clicking any white space in the 
diagram (to set the focus to the process and not any activity within the process), 
^ selecting the Counter tab of the Attributes view, and then adding the 
information. The data collected for the counter can be found in Table 22. 


Table 22 First counter defined for the Handle Order process 


Process Name 

Handle Order 

Counter Name 

Check Order Counter 

Source Trigger(s) 

User-defined trigger: Check Order Handling Policy Trigger 

Action(s) 

Add one 
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The second counter counts the number of times the Ship Order to Customer task 
completes, as signified by the defined trigger. The data collected for the counter 
can be found in Table 23. 

Table 23 Second counter defined for the Handle Order process 


Process Name 

Handle Order 

Counter Name 

Ship Order Counter 

Source Trigger(s) 

User-defined trigger: Ship Order Trigger 

Action(s) 

Add one 


By referring back to Figure 41 on page 64, you can see that the Check Order 
Handling Policy task is performed for every instance of the process while the 
Ship Order to Customer task is only performed if the order is not rejected. The 
difference between the two counters, when aggregated, provides the percentage 
of orders shipped. 

Before determining the percentage, the aggregate metrics based on these two 
counters must be defined. The first aggregate metric collects the data from the 
Check Order Counter. The aggregate metric is defined by opening the Business 
Measure Editor, ^ selecting the KPIs and Aggregate Metrics tab, ^ selecting 
Aggregate Metric in the Business Measure tree, and then adding the information. 
The data collected for the aggregate metric can be found in Table 24. 


Table 24 First aggregate metric defined for the Handle Order process 


Process Name 

Handle Order 

Aggregate Metric Name 

Check Order Aggregate Metric 

Metric Data Type 

Integer 

Aggregation Function 

Total 

Aggregation Source 

Check Order Counter 


The second aggregate metric collects the data from the Ship Order Counter. The 
data collected for the aggregate metric can be found in Table 25. 

Table 25 Second aggregate metric defined for the Handle Order process 


Process Name 

Handle Order 

Aggregate Metric Name 

Ship Order Aggregate Metric 

Metric Data Type 

Integer 
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Aggregation Function 

Total 

Aggregation Source 

Ship Order Counter 


After these two aggregate metrics have been defined, then the KPI can be 
defined, which relates to the goal of achieving an approval rate of 90% or better. 
The KPI calculates the percentage of approved orders by dividing the number of 
orders shipped (the Ship Order Aggregate Metric (only approved orders are 
shipped)) by the total number of orders (the Check Order Aggregate Metric). The 
data collected for the KPI can be found in Table 26. 

Table 26 Percent of Orders Fulfilled KPI 


Process Name 

Handle Order 

Strategic Goal 

The percentage of approved orders should be 90% 

KPI Name 

Percent of Orders Approved 

KPI Data Type 

Double 

Aggregation Function 

User-defined 

Aggregation Source 

Metric: Process Duration 

Use Target 

True 

Target 

90 (%) 

Lower Target Margin (%) 

95% (= 85.5%) 

Upper Target Margin (%) 

100% 


Dashboard design 

A dashboard is a role-based display that can summarize a vast amount of data 
into simple, intuitive measures to convey essential information. This information 
facilitates directed actions, decisions making, and optimization. The name 
dashboard is used since it is analogous to a car dashboard that serves a similar 
function within a car. However, it is important to be aware of information usually 
found in the general environment, but may not naturally occur on the dashboard. 
For example, a car dashboard has a speedometer, but a key, related piece of 
information is the speed limit sign. The speed limit sign is a threshold that is well 
known in the environment and is changing. This type of information may not be 
added to a monitor dashboard without a proper design of the KPIs, which must 
take into consideration the organization’s business goals and objectives. 
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Alerts and business results should be developed for display to the right people at 
the right time in a format based on a user’s role. The KPIs, metrics, and 
situations to be monitored are defined in a business measure model, which also 
provides the ability to tailor information availability and access to 
business-relevant data. 


Best practice: Users of dashboards should be able to quickly and easily: 

► View business results in real time and compare them with a historical 
perspective. 

► Receive an alert of an exception condition based on real-time analysis of 
KPIs. 

► Access related information to qualify business operations alerts. 

► Define automated responses to an exception condition. 

► Understand where changes in a business process can bring business 
advantage. 


Best practice: Some common mistakes that dashboard designers should try 
to avoid include 3 dashboards that: 

► Exceed the boundaries of a single screen. 

► Supply inadequate context for the data. 

► Display excessive detail or precision. 

► Express measure indirectly. 

► Include inappropriate display mechanisms. 

► Include meaningless variety. 

► Use poorly designed display mechanisms. 

► Encode quantitative data inaccurately. 

► Arrange the data poorly. 

► Ineffectively highlight what is important. 

► Are cluttered with useless decoration. 

► Misuse or overuse color. 

► Have an unappealing visual display. 

a. From “Effective Dashboard Design,” by Stephen Few, Perceptual Edge, 2004 

(http://sfarea.org/Dashboard%20Desi gn%200vervi ew. pdf) 
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What makes a good dashboard 

The key to a good dashboard is that it provides the proper information to the 
person who is responsible for the processes, so that this person can respond 
appropriately for urgent situations and can also provide feedback to WebSphere 
Business Modeler so that the processes can be improved. Thus, the WebSphere 
Business Monitor and its dashboards are a critical element of the toolset that 
makes the Business Innovation and Optimization lifecycle effective. 

A dashboard is a very visual type of technology, and should be designed to: 

► Provide the big picture. 

► Allow the user to zoom in on important specifics. 

► Provide links to supporting details. 


Best practice: When developing a dashboard, it is a good idea to create 
scripts of the use cases or user stories to help end users rapidly and 
effectively use the dashboard. Consider a glossary for acronyms used on a 
page. The glossary can be used for documentation by the team or provide 
flyover help. 


Best practice: A good dashboard should have positive answers to all of the 

following questions: 

► Does the dashboard provide decision makers with relevant 
performance-related data and facts? 

► Does the information presented on the dashboard inform the end user as 
to what directed action is required? 

► Does the information presented on the dashboard inform the end user that 
no action is required? 

► Does the information presented on the dashboard inform the end user that 
he/she has to be concerned? Is the value shown good or bad? 

► Does the information presented on the dashboard help the end user 
optimize the business or identify a performance issue? 

► In general, how does the value on the dashboard help the user to work 
smarter? 
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Best practice: Furthermore, here is a list of general guidelines for dashboard 

design: 

► Executives should not be the first to drive action from what they see on the 
dashboard. By the time it gets to them, subordinates should already be 
working the problem. Dashboards should show this. Scripts should be 
written this way. 

► A dashboard should focus on a single user role. Do not cross roles in the 
dashboard unless necessary (for example, a dashboard that handles two 
roles, or an ID administrator may want a business view and IT view). 

► Create pages that are task based. Do not mix a lot of news portlets, stock 
tickers, instance messages, and so forth, with portlets with business 
content. Just create separate pages for like-content. Create separate portal 
places to collect some of this, for example, my news, my contacts, my 
reports. 

► Watch out for portlets on a page that naturally should be connected (for 
example, all show West Region). If they should be connected by shared 
information, be sure to identify this. 

► Only show a trend if you can reasonably get trend data and it makes sense 
in the context. Make sure the trend symbol is understandable. 

► The symbology should be consistent across all of the dashboards. 

► Limit the amount of white space on the dashboard. 

► At the same time, do not overcrowd the dashboard. It is good to remember 
the seven plus or minus two rule. This is the number of elements that 
people can handle simultaneously (a group of related elements can be 
considered as a single element for this rule). 

► Limit the use of red/bad results on the screen. The dashboard is supposed 
to be pro-active, for example, head off problems. If we show a dashboard 
full of red/yellow, it can come across as being reactive. 

► Make sure charts and graphs have clearly understood meaning and units 
of measure. 

► Make legends available as hyperlinks or flyovers. No need to take up the 
visual space. 

► Consider providing data comments/annotations for values out of the norm 
(potentially it can just be a news-of-the-day type of display). This lets 
everyone know that the out of norm value is being addressed. 

► In the tabs, use terms that are indicative of the actual content, for example, 
sales dashboard. 

► Always get a semi-formal review from your peers. Do not settle for a scan, 
but challenge them to review it stringently. 

On a related note, be sure they have time to review it and the appropriate 
context is provided (a script, glossary, and measurements definitions go a 
long way in this regard). It is better for us catch issues early. 
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Real-time versus historical reporting 

Historical reporting is very common within organization’s today. There are many 
reporting tools on the market that can sift through a performance database and 
inform management as to how well the organization performed within past 
periods of time (for example, last month, last quarter). These types of reports are 
important with the Business Innovation and Optimization lifecycle. 

However, traditional historical reporting, which is available in WebSphere 
Business Monitor, should not be confused with capabilities and benefits of 
real-time reporting that are available from the WebSphere Business Monitor, 
which include: 

► Real-time state of business measured against targets (scorecard): 

- Trends of KPIs (revenue, cost, response time, etc.) 

► Business process monitoring (per instance): 

- Status of a particular insurance claim 

- Response time or execution time limit exceeded for a task or process 

► Business process statistics that are not available through traditional reporting 
tools: 

- Average duration per activity, cost per activity, decision branching ratios 

► Alerts of events that require action: 

- Revenue drop 

- Inventory shortage 

- Time or cost increase 

► Detection and alerts for critical business situations: 

- High value order arrives while out of inventory and supplier decommitted 

The WebSphere Business Monitor dashboards that provide real-time reporting 
are the Active Instances view, the Alerts view, the Gauges view, the KPIs view, 
the Organizations view, the Process Diagrams view, and the Scorecard view. 
The Reports view and the Dimensions view (including DB2® Alphablox) provide 
historical reporting. With its combination of historical and real-time reporting, the 
WebSphere Business Monitor allows users to be more proactive by being able to 
react, in real-time, to unwanted trends before they become critical. 


Types of dashboards 

There are nine types of predefined dashboard portlets or views available. The 
views can be plugged into a dashboard. The views can also be customized for 
use in the dashboard. 
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The different views can be mixed and matched within a dashboard to highlight 
the proper information for the user. This is why it is important to have a good 
understanding of the purpose of each dashboard as they are being put together. 

The following sections describe these dashboards. 

Active Instances view 

This view displays the details of a process at run time (Figure 42). 
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Figure 42 Active Instances view 

Viewing the details of processes and their metrics helps you oversee your 
business by displaying all the information of the running instances as they 
happen. Using the Active Instances view, you can monitor values of metrics that 
belong to an aggregate business measure group. 

The available process instances for a selected business measure group are 
displayed, enabling you to view the values of their associated metrics, keys, 
timers, and counters and how they are progressing. 

You can perform a drill-down on child instances of a parent instance to view the 
underlying activities. The business measures that are displayed in the view must 
either be predefined business measures common to all processes, or must have 
been defined in WebSphere Business Modeler. 

You can also perform administrative actions on the process instances that are 
being executed by WebSphere Process Server. The allowed administrative 
actions are: 

► Suspend — Suspends the selected instance 

► Resume — Resumes a previously suspended instance 

► Terminate — Terminates the selected instance 
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You can establish a wire (a connection) from the Alerts view targeting the Active 
Instances view. Hence, when you can select an alert source from the Alerts view, 
the associated process instance that triggered the alert is displayed in the Active 
Instances view. You can also establish a wire from the Active Instances view to 
the Process Diagram view, so that you can visually see which activities in a 
process have been executed. 

When the Active Instances view is configured, you can observe, in the view 
mode, a table listing the process instances and the values of the business 
measures. You can sort the entire displayed list of process instances based on 
sortable measures, perform administrative actions, and perform a drill-down on 
instances that contain activities, local sub-processes, or global (reusable) 
sub-processes. 

Alerts view 

This view displays alerts that notify business users of defined situations when 
they take place at run time, thus enabling them to act accordingly (Figure 43). 
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Figure 43 Alerts view 


When a particular business situation that is defined in the Business Measures 
Editor (of WebSphere Business Modeler) takes place at run time, an alert can be 
sent to one or more specified WebSphere Business Monitor users. For example, 
assume that a manager of a claim processing unit has set a ceiling for the 
amount of a claim (Figure 44). If the claim amount is exceeded, this is considered 
by the manager to be a situation that requires immediate attention. 
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Claims Process - Alerts 
Details: 

Alert time: 

|Apr 1, 2006 12:37:48 PM 
Subject: 

|Large Claim Received 

Business Situation Name: 
jLargeClaimSituation 

Body: 

|A claim for $52500.0 has been received. 

Back | 

Figure 44 Alerts Details view 

Such situations are defined in the Business Measures Editor. When these 
situations occur at run time, they trigger alert notifications that are sent to the 
appropriate recipients. By receiving alerts in the Alerts view, the unit manager 
can take the necessary actions as situations take place. 

The alerts displayed in the Alerts view are based on the configuration defined in 
the Action Manager, in terms of the addressed recipients, subject, and body text. 
The runtime values are captured from the situation event pertaining to the 
relevant instance. Each alert provides you with details regarding the time at 
which the situation took place, the title of the alert, the business situation name, 
the alert body text, and the situation event that has resulted in the current alert, if 
selected to be included in the alert message. 

It is worth noting that you can highlight the diagram of a process instance in 
which the business situation took place. In order to display such a diagram, you 
have to establish a wiring connection from the Alerts view targeting the Process 
Diagrams view. By creating this wiring connection, you can automatically 
highlight in the Process Diagrams view the process instance path that is 
associated with the alert source you choose from the Alerts view. 

When you open the Alerts view, you can: 

► Display your alerts and browse them if listed on more than one page. 

► Sort the entire alerts list based on sortable columns. 

► Read the alert details and the situation event data attached with it. 

► Mark one or more alerts as read or unread, or remove them. 
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The removal of the alerts only hides them from being shown on the Alerts 
view table; however the alerts can still be seen in the ACTIONMGR_ALERTS 
table in the RUNTIME database. 

Gauges view 

This view allows you to monitor key KPIs represented by graphic gauges or dials 
(Figure 45). 
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Figure 45 Gauges view 


Expressclaim aggregates detail 
Average Claim Duration 


ExpressClaim aggregates detail 
Percent Using Express 



Gauges enhance the ability of the user to visualize information because they 
represent KPI values using the appearance of common instruments like a 
speedometer or tachometer in an automobile. A dial is used to represent the 
position of the value of KPI in two different ways. The KPI value could be 
monitored relative to the lower and upper limits of the KPI, or relative to the target 
of the KPI. The Gauges view focuses on representing numeric KPIs that belong 
in a business measures model. Each gauge represents the value of a single KPI. 

This view requires that a business measures model contains the KPIs that you 
want to monitor. If you choose to monitor one or more KPIs relative to their 
targets or their limits, then these must be defined in WebSphere Business 
Modeler (see “Business measure modeling ” on page 25). Otherwise, you will not 
be able to monitor these KPIs in the view mode. 


Best practice: Make the difference between the lower and upper gauge limits 
a multiple of 5. This avoids awkward decimal points in the display. For 
example, specifying 0 to 100 displays tick marks of 0, 20, 40, 60, 80, and 100. 


Reports view 

The Reports view displays performance reports on historical values of KPIs 
relative to a time axis. The analysis is typically represented in tables and graphs. 
You can break down the displayed analysis data based on a selected dimension. 
This requires you to have those KPIs already defined as dimensions in the 
business measures model (defined within WebSphere Business Modeler). 
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There are four types of analysis that can be performed on historical data of a 
specific subject area. The supported analysis types are: 

► Basic: This graph displays the values of the KPIs (Figure 46). 


Claims Process - Dimensional Duration and Amount by Path 


1 5 //? . □ 


Measures I Elapsed Duration (Hours) I 



0 Express ^ HighTouch 


ClaimPath ti 

ClaimType t| 

Bodily Injury t| 

Fire t| 

Flood t; 

ClaimPath ti 

182 

414 

51 

45 

Express t| 

23 


24 

23 

HighTouch ti 

241 

414 

69 

68 


Figure 46 Basic Reports view 


► Control: This graph displays the variation in the KPIs that you are measuring 
and can help you understand and reduce the variation and is mostly used for 
quality control purposes. The allowable variation is three times the standard 
deviation of the data. 

► Quartile: This graph displays the KPI value of the boundary at the 25th, 50th, 
or 75th percentiles of a frequency distribution divided into four parts, each 
containing a quarter of the population. 

► Trend: This graph (Figure 47) displays the analysis of the changes in a KPI 
over a period of time using Exponentially Weighted Moving Average (EWMA). 
The EWMA is the average of historical values that are given weights (by a 
weighing factor), which exponentially decrease by time. 
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You can select any analysis type, and the output report will be generated in the 
form of a table and chart. The Basic analysis type permits adding multiple KPIs. 
For the other analysis types, you can select only one KPI. 

In addition to the defined KPIs that are part of the selected subject area, the 
report can provide two predefined KPIs. Those Reports view KPIs are the Sum of 
New Items and Sum of Resolved Items. Your analysis can include either one or 
more of these predefined KPIs, or one or more of the modeled KPIs. 

Furthermore, the values of KPIs that are associated with process instances can 
be filtered based on associated employees. By establishing a wiring connection 
from the Organizations view targeting the Reports view, you can automatically 
filter your report data based on the assigned employee that you select from the 
Organizations view. 

Dimensions view 

This view allows users to generate multidimensional reports that analyze 
different business aspects on historical business performance data. For 
example, Figure 48 shows a drill down of the data shown in Figure 46 on 
page 77. 
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Figure 48 Dimensions view 

Dimensional analysis provides business insight by summarizing KPIs. It 
organizes data into levels of detail that you can drill down to extract significant 
information. A dimension is a conceptual axis over which a business is analyzed. 
For example, a retail business performance might be analyzed over time, 
products, and stores. For this business, time, products, and stores are 
dimensions. Each of the dimensions has one or more levels, which together 
define the overall hierarchy of the dimension. For example, the time dimension 
might have year, quarter, and month levels hierarchically nested. 

Let us assume you have collected a lot of data (for example, sales figures for 
every product your company makes), and you have to retrieve information from 
this data, and find answers to questions such as: 

► What are the total sales for each product by store? 

► Which products are selling best over time? 

► Who is your highest-performing salesperson? 

To answer these and other questions, you can use the Dimensions view to 
extract, organize, and summarize your data. You can use the view to analyze the 
data, make comparisons, detect patterns and relationships, and discover trends. 
The way you want to represent your data in the Dimensions view depends on 
your selection of row, column, and page dimensions; those parameters visualize 
the selected dimensions in tables and charts. For example, a subject area can 
include two dimensions: a location dimension with country, region, and city 
levels; and a product dimension with product category and product name levels. 
In this case a metric for total sales could then provide sales figures for each 
product and type in each city, region, and country. 
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This view requires that a business measures model must have been defined 
within WebSphere Business Modeler. The business measures model contains 
defined dimensions and KPIs, which are required for the multidimensional report 
for each subject area (business measures group). 

While using the Dimensions view, the user can: 

► View the generated multidimensional report using the view mode of the 
Dimensions view. 

► Modify the layout of the dimensions of the generated report. 

► Perform a drill-down to all levels of a dimension. 

► Filter the generated report data. 

DB2 Alphablox 

WebSphere Business Monitor monitoring, analysis, and reporting capabilities are 
enhanced by DB2 Alphablox supporting services. DB2 Alphablox provides a set 
of supporting services for further data analysis and representation capabilities. 

DB2 Alphablox technology is directly embedded in WebSphere Business Monitor 
dashboard views. In a rich business context, DB2 Alphablox enables extensive 
data analysis and representation capabilities by the use of visual Blox, as in the 
context of building blocks, to create highly interactive tables, graphs, charts, and 
reports: 

► Blox — Blox, as in the context of building blocks, is an element in your 
dashboard view that you can use to control and customize your data 
presentation (Figure 49). 
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Toolbar 



Page Filter 


Data layout Panel 


Grid Chart 


Figure 49 Alphablox PresentBiox view 

Each of the major Blox enables users to interactively explore and analyze data. 
For example, you can export data to Adobe PDF files or Microsoft® Excel 
spreadsheets, hide columns in a report, create traffic-light style reports based on 
specified column values, and alter the format of a displayed chart. You can also 
drill, pivot, and sort data in tables. 

Blox types are listed in Table 27. 


Table 27 Types of Blox 


Blox 

Description 

Example 

Usage 

Grid 

A table-like 
representation of 
data that includes all 
required functions to 
manipulate the data 
in a multidimensional 
way. 

You can drill up, drill down, 
show, hide sort, pivot, and 
swap axes. 

Used in most views except the 
Process Diagrams and Export 
Values views. 
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Blox 

Description 

Example 

Usage 

Chart 

A graph-like 
representation of 
data that provides 
advanced 

visualization of data. 

You can visualize your data 
through a large number of 
chart types including bar, 
line, pie, scatter, and bubble 
charts, as well as bipolar and 
dual-axis charts. 

Only displayed in the Reports and 
Dimensions views. 

Data 

layout 

panel 

A tree-like 

representation of the 
dimensions that are 
used in the analysis. 

You can move and reorder 
dimensions across axes. 

Only displayed in Dimensions views. 
It is not displayed by default. You 
should click the Show Layout button 
from the toolbar to show the data 
layout panel. 

Page 

filter 

A drop-down list 
representation of a 
dimension and its 
members. 

You can view and analyze 
your data according to a 
dimension or one of its 
members. 

Only displayed in the Dimensions 
view. 

Toolbar 

A toolbar that offers 
easy access to 
common data 
analysis 

functionalities by the 
use of a menu bar 
and a set of buttons. 

You can use the menu bar 
and the buttons to perform 
multiple operations on grids 
and charts. 

Only displayed in the Reports and 
Dimensions views. The toolbar 
availability depends on the mode of 
the view as follows: 

In the Configuration and Edit modes, 
the toolbar is displayed by default. 

In the View mode, the toolbar is 
hidden and is only displayed when 
you expand the view. 

Present 

Blox 

A combination of one 
or more of the grid, 
chart, data layout 
panel, toolbar, and 
page filter into a 
single, 

well-orchestrated, 

interconnected 

scene. 

In a PresentBlox, drilling 
down in the grid 
automatically updates both 
grid and chart with the new 
data. Also, selecting a 
different dimension or 
changing the dimension 
members in the page filter 
updates both grids and 
charts with the new data. 

Only displayed in the Reports and 
Dimensions views 


You can access DB2 Alphablox help from the dashboard if you need assistance 
on any Blox. 
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Best practice: Modify the Blox to make it more user friendly in the dashboard. 
For example, modify the KPIs names to make them more user friendly 
(currently they do not imply the aggregation function used), or change the 
duration values from milliseconds to hours (for example) by dividing the 
aggregation definition by 3,600,000. 


KPIs view 

This view allows business users to monitor KPIs by displaying all KPI information 
at a glance from runtime data (Figure 50). 
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Below limit Q Within limits Q Above limit 
Figure 50 KPIs view 

One of the most valuable ways of monitoring business performance is through 
using KPIs. Consequently, KPIs differ depending on the business. For example, 
in the domain of telesales, answering customer calls is a key business activity. 
The percentage of calls answered within the first minute may be one of its KPIs. 

When selecting KPIs, you should choose them to reflect the goals of your 
business, be critical to its success, and allow for corrective action by earlier 
detection of drawbacks. 
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This view requires that business measures, including the KPIs that you want to 
monitor (with defined upper and lower limits), must have been defined within 
WebSphere Business Modeler. Otherwise, the KPI status is not displayed. 

Organizations view 

This view (Figure 51) provides business users with the means to view the list of 
organizations and employees within their organizational structures by retrieving 
employee information from any user registry supported by WebSphere Portal. 



Figure 51 Organizations view 


Among the benefits of the Organizations view, you can search for a specific 
organization and view its associated employees. You can also search for an 
employee name in a particular organization or in the entire organizational 
structure. The search results would be the matching employee names, each with 
the associated e-mail address. 

The usage of this view is coupled with the Reports view, as a report can be 
filtered based on the assigned employees. By establishing a wiring connection 
from the Organizations view targeting the Reports view, you can automatically 
update your report process instances data based on an employee or 
organization selected from the Organizations view. 

The Organizations view retrieves the registry directory information, and displays 
the hierarchy of the organizations and their associated employees in the form of 
a tree. Each item in the tree is rendered as a link. After wiring the Organizations 
to the Reports view, you can click any of the items in the Organizations view, and 
the Reports view data gets filtered. In the case of clicking an organization, the 
process instances data in the Reports view are filtered based on all the 
employees belonging to the selected organization. 
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Process Diagrams view 

This view (Figure 52) displays process diagrams and process instance diagrams. 
You have to install a compatible scalable vector graphics (SVG) viewer to view 
diagrams in the Process Diagrams view. 



Figure 52 Process Diagrams view 


The Process Diagrams view displays diagrams of the top-level processes. If the 
selected process model contains sub-processes, you can drill down to view the 
underlying items. The numbers of ready and running instances of the process 
are annotated on the displayed diagram. 

You can also have the activities of a process instance highlighted. In order to do 
so, you have to establish a wiring connection between the Process Diagrams 
view and the Alert or Active Instances view. When an instance is selected from a 
source view, the Process Diagrams view identifies the involved process instance 
activities, whose states are ready, running, or completed, and marks them with 
red frame (as in Figure 52). 

Wires can be set from the Alerts view to the Process Diagrams view and from the 
Active Instances view to the Process Diagrams view. By creating a wiring 
connection from the Alerts view to the Process Diagrams view, you can 
automatically update the displayed process instance diagram in the Process 
Diagrams view, based on the alert source you select from the Alerts view. The 
same applies to the wire from the Active Instances view to the Process Diagrams 
view. The displayed process instance diagram can be based on the instance that 
you select in the Active Instances view. 


Scorecards view 

This view (Figure 53) allows users to monitor KPIs grouped based on some 
configurable business perspectives, where for each KPI information is available 
regarding the position of the KPI relative to its target value. 
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Figure 53 Scorecard view 

A scorecard is a set of KPIs that are linked to objectives and goals of a specific 
business area. Executives and other business users select the essential few 
KPIs, pertaining to their various areas of responsibility, and place them in 
perspectives (categories) on their scorecards. Thus, each executive would easily 
keep a close eye on runtime values of vital numeric KPIs, monitoring them 
against defined targets. 

This view requires that business measures must have been defined within 
WebSphere Business Modeler, including KPIs with defined targets. Otherwise, 
the KPI status, target, and score is not displayed. Non-numeric KPIs cannot be 
monitored using the Scorecards view. 

Scorecards typically include four perspectives: Financial, Customer, Learning 
and Growth, and Internal Business Process. The Scorecards view provides you 
with these four default perspectives, and allows you, as well, to define additional 
perspectives that may satisfy your business measurement scope and need. 
Within each perspective, you can monitor one or more KPI’s runtime values, 
along with their targets and scores. 


Configuring dashboards 

The WebSphere Business Monitor allows us to define and build indicators based 
on KPIs defined in WebSphere Business Modeler. The indicators are displayed 
on dashboards and greatly support the activities of the management system. The 
WebSphere Business Monitor automates indicators in real time. Hence, this 
business process behavior measurement capability enables the feedback loop 
and gives the right visibility to management to take decisions and decide process 
improvement. 

Each of the predefined dashboard views can be configured within the 
WebSphere Business Monitor environment. Table 28 lists the views and the 
types of configuration that can be done. 
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Table 28 Configuration options for WebSphere Business Monitor views 


View 

Type of configuration 

Activity 

Instance 

► Selecting a certain business measures group whose instances are to be displayed 

► Selecting the KPIs whose values are to be displayed 

► Selecting the sorting options and currency units (where applicable) for values of 
metrics 

► Defining a filtering criteria, if necessary, to limit the displayed KPIs, based on a 
defined expression 

► Specifying the number of instances to be displayed per page 

► Showing or hiding informational text 

Alerts 

► Specifying the number of alerts to be displayed per page 

► Defining the database refresh rate for retrieving new alerts. The refresh rate is the 
interval of time, in seconds, that the WebSphere Business Monitor server waits to 
access the database to check for and retrieve the available alerts. 

► Selecting colors representing read and unread alerts 

► Showing or hiding the situation event in the alert details 

► Showing or hiding informational text 

Dimensions 

► Selecting a subject area of interest 

► Selecting the row, column and page dimensions 

► Selecting the metric that represents the report data 

► Modifying visual properties and report settings (if required) 

Gauges 

► Selecting the KPIs whose values are represented using dials 

► Selecting the gauges layout 

► Specifying whether the dials represent the values of the KPIs relative to the limits of 
the KPIs or relative to the targets 

► Selecting the colors to be used for representing sectors of the gauges 

► Specifying the minimum and maximum boundaries (end points) of the displayed 
gauges 

► Showing or hiding legends 

► Showing or hiding informational text 

KPIs 

► The KPI name 

► The value of the KPI 

► The value of the KPI lower limit, upper limit, or both, based on the KPI value The 
status of the KPI value relative to the KPI lower and upper limits 

Organizations 

► The source of the user registry 

Process 

Diagrams 

► Selecting a Business Measure Model and a process diagram 

Reports 

► Selecting a subject area, and the associated KPIs of interest 

► Selecting the analysis type (Basic, Quartile, Control, or Trend) 

► Setting the starting date and end date of the interval for the report, and the 
frequency for displaying report data 
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View 

Type of configuration 

Scorecards 

► Customizing perspectives, if necessary 

► Selecting KPIs for the perspectives 

► Selecting one or more of the following columns to be displayed: KPI Value, KPI 
Target, and KPI Score 

► Selecting the view layout 

► Selecting icons to represent the status of KPI value relative to its target 

► Showing or hiding legend 

► Showing or hiding informational text 


Best practice: Establish organization guidelines for portlet authorizations. 
Keep in mind that some portlet updates require administrative privileges while 
other updates only require user privileges. 


Cooperative views 

WebSphere Business Monitor views become cooperative by establishing wires 
(connections) from a source view targeting a target view. This means that actions 
performed in one view updates one or more other views. For every two 
cooperative views, the created wire is in one direction. That is, one view is 
regarded as the source view, and the other is regarded as the target view. The 
target view reacts to the data it receives and is updated automatically. You can 
establish multiple wires between the same two views, where in each wire 
connection a particular type of data is selected to be sent and received. 

Note that in order to establish a wire between two views, these views must be on 
(plugged into) the same dashboard. 

The configuration of the wires between views occurs within the Portlet Wiring 
Tool provided in the WebSphere Portal. Table 29 lists the possible cooperative 
views’ wires that can be created by the administrator on a dashboard. 


Table 29 Supported cooperative views wiring 


Source view 

Target view 

Description 

Active Instances 
view 

Process Diagrams 
view 

You can choose to display the diagram that represents a 
particular process instance. To display such a process instance 
diagram, you have to establish a wire from the Active Instances 
view targeting the Process Diagrams view. When a process 
instance is selected from the Active Instances view, the 
Process Diagrams view displays the diagram of the selected 
instance. 
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Source view 

Target view 

Description 

Alerts view 

Process Diagrams 
view 

By creating a wire from the Alerts view targeting the Process 
Diagrams view, you can automatically display the process 
instance diagram in the Process Diagrams view, based on the 
alert source you select in the Alerts view. 

Alerts view 

Active Instances 
view 

A wire can be established from the Alerts view targeting the 
Active Instances view. Thus, when you choose an alert from 
the Alerts view, the associated process instance is displayed in 
the Active Instances view with the associated metrics. 

Organizations 

view 

Reports view 

A wire can be established from the Organizations view 
targeting the Reports view. You can automatically filter your 
report data based on the assigned employee that you select in 
the Organizations view. 


Setting up alerts 

Alerts and notifications are set up through the administrative functions of the 
WebSphere Business Monitor Adaptive Action Manager. The Action Manager 
associates actions with situations that have been defined in the business 
measure model and detected by the Monitor Server. WebSphere Business 
Monitor emits the situations as common base events, and the Action Manager 
receives and parses these situation events, selects appropriate actions based on 
predefined rules and policies, and invokes a selected action or set of actions. 

The Action Manager produces two types of actions: notification type actions and 
service invocation actions. Notification type actions take the form of e-mail, SMS, 
pager message, or a dashboard alert (as described in this paper). Service 
invocation actions invoke a Web service or a BPEL process through a Web 
service invocation. 

If the appropriate action is a dashboard alert, the Action Manager extracts the 
data required for the creation of the alert notification record from the received 
situation event, and inserts this record in the WebSphere Business Monitor 
Runtime database. This record is picked up by the Alerts view in the WebSphere 
Business Monitor dashboard. 
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Assembling and deploying 

Assembling and deploying are the second and third activities of the Business 
Innovation and Optimization lifecycle. However, these activities are not the focus 
of this Redpaper. Thus, these activities are described only generically to provide 
the context for and the connections between modeling and monitoring. More 
specific information about assembling and deploying can be found in other IBM 
resources . 1 

You can use WebSphere Business Modeler to model and simulate a business 
change, and then implement that change manually. However, if you want to use 
the To-Be business model to generate the BPEL code that forms the basis of 
your runtime implementation, you must design a model that generates robust, 
usable BPEL code with the editing mode for WebSphere Process Server. If your 
business analyst is technically proficient, he can create a To-Be model that is 
optimized for exporting to BPEL. Otherwise your business analyst might pass the 
model to a solution architect, who will adjust the model as necessary to ensure 
that the generated BPEL provides a good foundation for the process that you 
want to implement. Then the BPEL process is exported from WebSphere 
Business Modeler to WebSphere Integration Developer. 


Best practice: For minor changes to a process, the WS-BPEL process within 
WebSphere Integration Developer can be changed, tested and deployed as a 
new minor version of the process. You want to make the changes in a way that 
makes it easier to reuse those changes after you update the BPEL from 
another iteration through the WebSphere Business Modeler. 


Best practice: For major changes to a process, the WS-BPEL model should 
be re-generated from WebSphere Business Modeler and imported into 
WebSphere Integration Developer. From there, the process assembly would 
continue using the pre-existing assets from the previous business process. 
Since these are all external to the business process, process assembly is 
minimal and, in most cases, can utilize the auto-connect function if these are 
considered as part of model development standards. For information outlining 
the recommended steps when moving from WebSphere Business Modeler to 
WebSphere Integration Developer, see: 

http://publib.boulder.ibm.com/infocenter/ieduasst/vlrlmO/index.jsp? topi c= 

/com. i bm. i ea .wpi_v6/wbmodel er/6 . 0/Model erToWID.html 


1 IBM Redbook: Business Process Management: Modeling through Monitoring Using WebSphere 
V6 Products, SG24-7148 
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Assembling and deploying relates to the transformation, packaging, distribution, 
and installation of the models created during the modeling activity. The 
transformation involves applying the model-driven architecture (MDA) approach 
to transform platform-independent models to technology-specific 
implementations. The packaging and distribution is driven by the logical system 
topology for the running of the models. 

The performance, or running, of the processes is implicit in the Business 
Innovation and Optimization lifecycle, after they have been deployed. The 
WebSphere Process Server is used to run a process and provide data for the 
WebSphere Business Monitor. The basic steps for running the processes are: 

► Export the application from WebSphere Integration Developer. 

► Configure the Process Server. 

► Install the application in WebSphere Process Server. 

► Run the application. 

The runtime of WebSphere Process Server enables model-driven operations by 
linking the execution environment with the models that have been deployed, and 
by instrumenting the run-time platform to: 

► Monitor business metrics, KPIs, and critical business situations in real time. 

► Provide a feedback loop from monitoring and analysis back to model 
improvement and redeployment. 

► Inject executable business rules to allow for dynamic changes of business 
behavior. 


Managing 

Managing is the fourth and final activity of the Business Innovation and 
Optimization lifecycle. This activity provides real-time visibility and analysis of 
business information for timely and coordinated actions. The following two 
sub-sections separately review the real-time visibility (monitoring) and analysis 
(with adapting) aspects of managing. 

Monitoring 

A Business Innovation and Optimization lifecycle is fully achieved only if an 
appropriate feedback loop exists. The feedback loop should not only trace an 
indicator, but also set a target based on business goals and objectives that the 
indicator will be measured against. 
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Such a feedback loop insures that a manager can perform the following activities 
on a regular basis: 

► Verify process correction efficiency. 

► Analyze the trend and detect out-of-target situation. 

► Identify problems in business process practice to be improved, that is, 
maintain a permanent re-engineering movement. 

► Assign a person responsible to develop a plan of action to recover the 
performance. 

The WebSphere Business Monitor is the feedback mechanism (Figure 54) that 
provides visibility of performance problems on a real-time basis and the 
opportunity for timely actions to optimize business operations and IT 
infrastructure. Process visibility allows the business to identify issues or 
bottlenecks as they occur, rather than through indirect reporting, which may not 
have an accurate picture of what is occurring at the time that it is occurring. 
Real-time business measures, especially KPIs, provide information that decision 
makers can use to make on-the-fly or long-term modifications. 
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Figure 54 WebSphere Business Monitor as feedback loop component 


The WebSphere Business Monitor allows administrators and managers to 
access performance data in real time by tracking the status of artifacts, 
resources, and business processes. In addition to this real-time state 
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information, the monitoring activity can include the aggregation of historic data. It 
can invoke actions and alerts when particular business patterns occur. 

Managers can see how projects are performing and what specific issues require 
resolution. Executives can easily view business metrics and alerts tailored to 
their areas of responsibility. Information is displayed through dashboards that 
enable roles-based data and industry-oriented reporting. Features of the 
WebSphere Business Monitor include: 

► The presentation of the state of business performance measured against 
targets (scorecard), for example, new product revenue 

► The ability to track business process flow, for example, the status of a 
particular insurance claim 

► The ability to monitor metrics in customizable dashboards, for example, 
duration and cost 

► The detection and alerting of anomalous situations, for example, a gold 
customer order with no inventory and supplier decommitted 

► The ability to feed actual values back to the model 

Analyzing and adapting ''-a 

The WebSphere Business Monitor and its dashboards capture real-time and 
historical data to allow a business to analyze and evaluate the performance of 
the organization as measured through KPIs and customized reports. Analysis of 
real-time event data and other business data, including historical data on 
business operations, is necessary for diagnosing business performance 
problems. It is also critical in evaluating the various decision alternatives and 
planning the appropriate corrective action for any particular business 
performance management situation that is detected. 

The analysis capabilities in the WebSphere Business Monitor also support 
strategic change as it pertains to business, operations, organization, and 
technology necessary to achieve business performance goals. Such analysis 
can involve evaluation of choices and their value consequences. Business 
transformation and consulting service methodologies and tools typically apply to 
such analysis. 

Adapting to the performance measuring capabilities provided by the WebSphere 
Business Monitor can be either tactical or strategic in nature. 

The tactical approach usually involves a line-of-business user that reacts to a 
real-time dashboard. Exception conditions are flagged based on metrics defined 
in the business measure models. If an alert is triggered by a business condition, 
the quick responses can be employed to handle the situation. This step can be 
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automated. Examples of actions performed in response to alerts include 
reassigning work items or changing their priority, modifying process structure, 
altering resource allocations, changing rules, or modifying trigger conditions for 
business situations. 

The strategic aspect of adapting involves a more complex business 
transformation. Based on information derived through analysis, managers can 
implement and prioritize major business transformations, such as redesigning a 
process, adding new lines of business, redeployment of assets and resources, 
and major acquisitions of technologies or business capabilities. 

Using reporting tools 

Other reporting tools can be added to the Business Innovation and Optimization 
solution to supplement the WebSphere tools and runtime. That is, business 
intelligence tools can perform analysis of the performance results of the 
WebSphere Business Monitor through access of the WebSphere Business 
Monitor performance warehouse (a historical database). 

Feeding Monitor results back into Modeler 

You may want to feed the values captured by WebSphere Business Monitor back 
into the model and perform simulation or analysis to further refine the solution. 
Once the process model has been executing for some time, the actual values 
can be exported to an XML file and imported back into WebSphere Business 
Modeler for further analysis on the process (Figure 55). Currently, only the 
processing durations and decision point percentages can be imported to 
WebSphere Business Modeler. 
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Figure 55 Exporting WebSphere Business Monitor data 
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As in keeping with the idea of a Business Innovation and Optimization lifecycle, 
you must: 

► First export a process from WebSphere Business Modeler. 

► Assemble and deployed the process with WebSphere Integration Developer. 

► Run the process with WebSphere Process Server. 

► Monitor the process with WebSphere Business Monitor. 

► Export the results (an XML file) from WebSphere Business Monitor. 

► Import the results into WebSphere Business Modeler. 

You must create a new simulation profile to take advantage of the updated 
values in simulation. Based on the new and more realistic data, you can rerun 
simulation and perform analysis to fine-tune the process model. 

To import WebSphere Business Monitor results, perform these steps: 

► In the Project Tree of WebSphere Business Modeler, ^ right-click and select 
Import. 

► In the WebSphere Business Modeler import dialog, select Monitoring result 
(.xml) and then continue with the wizard. 


Examples 

The two examples, Verify Account (from the fictional JK Enterprises) and Handle 
Order (from the fictional ClipsAndTacks, Inc.), are continued for monitoring, 
analyzing, and adapting in the following two sub-sections. 


Verify Account process 

The KPIs defined in WebSphere Business Modeler and placed in a dashboard 
for WebSphere Business Monitor have been providing real-time and historical 
data for the new and improved Verify Account process (Figure 56). 
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Figure 56 Dashboard for the Verify Account process 


The average duration for processing a new account easily satisfied the target of 
8 hours by being 3.2 hours over the last three months. This is longer than the 
estimated time derived from simulation (which was about 1.15 hours). The actual 
time was satisfactory, so no immediate changes to the process were planned. 
Three times an alert signaled that the duration did exceed the 8 hours, but a 
single instant message to the Account Manager took care of the situations 
quickly. Thus, the percentage of new accounts that exceeded the 8 hours was 
much less than the 14.5% target. 


Handle Order process 

Observations of the results from the WebSphere Business Monitor are continual, 
with the following formal reports due at one, three, and six months following the 
launch of the automated process. The KPIs revealed that some aspects of the 
revised process have been successful: 

► Time spent completing and submitting an order has been reduced by 60%. 

► Costs associated with a completed order have been reduced by 17%. 

The number of times that the order processing duration exceeded three days 
was few and far between. The occurrences were usually due to an absence of an 
Order Manager, and so their supervisor would step in and take the occasional 
order to stop any delays. 

While order handling costs are now lower, and the submission process is shorter, 
a bottleneck is occurring for orders that require manual approval. Managers are 
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still taking an average of 2.5 days to approve orders. From the observed data, it 
appears that each manager has a higher than expected number of orders to 
review and approve, resulting in a backlog of pending orders. 

As a result of continuing the pursuit of the high-level objective of attracting new 
customers, ClipsAndTacks' management has decided that the order submission 
process must be made more convenient for customers, and that the Handle 
Order process has to be able to fill orders in a shorter amount of time. 

To investigate the options for more improvements, the results of the WebSphere 
Business Monitor are exported so that they can be imported by the WebSphere 
Business Modeler. A few simulations show that the approval bottleneck results in 
increasing wait times as customer use of the Web portal increases. 

Increasing the number of available order managers to approve orders results in 
the company incurring more costs associated with the order process. However, a 
potential change in the automatic approval policy by instituting a customer rating 
system is simulated. 

In the new system, the order threshold is raised to $1250 for silver customers 
and $1 750 for gold customers. The actual rating is based on the number of 
orders received and paid for on time. 

Because the available credit threshold is being raised to this level, another 
change is instituted in the flow of approved orders. If an order is automatically 
approved based on the revised business rules, but the customer's account is 
found not to be in good standing, the order is cancelled outright rather than being 
sent for review. The assumption is that the higher credit limits should make it 
easier for customers to order all of their required supplies, but offering greater 
credit comes with the risk of greater loss if the account is not settled. This 
solution does not add any costs to the process, and continues to keep order 
fulfillment time low, since more orders move through the process without 
requiring human intervention. It also meets the high-level business objective of 
improving customer satisfaction. 

The following is a summary of revisions made for the Handle Order process 
based on the analysis of the WebSphere Business Monitor results: 

► Silver customers can order up to $1250 of merchandise without review. 

► Gold customers can order up to $1750 of merchandise without review. 

► Any account customer whose account is not in good standing will have their 
orders cancelled. 
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